Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

go1: internal compiler error: in bind_field_or_method, at go/gofrontend/types.cc:7537 #1331

Closed
alberts opened this issue Dec 8, 2010 · 17 comments

Comments

@alberts
Copy link
Contributor

alberts commented Dec 8, 2010

What steps will reproduce the problem?

This bug is hard to make reproducable, since it depends on having a bunch of our
packages in a directory that is included with a -I.

If you can't spot an obvious problem in the code where the internal compiler error
occurs, I'll see if I can come up with a test case.

What do you see instead?

go1: internal compiler error: in bind_field_or_method, at go/gofrontend/types.cc:7537
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html>; for instructions.

Which compiler are you using (5g, 6g, 8g, gccgo)?

gccgo

Which operating system are you using?

linux

Which revision are you using?  (hg identify)

URL: svn://gcc.gnu.org/svn/gcc/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 167582
@rsc
Copy link
Contributor

rsc commented Dec 8, 2010

Comment 1:

Labels changed: added gccgo.

Owner changed to i...@golang.org.

Status changed to Accepted.

@ianlancetaylor
Copy link
Contributor

Comment 2:

Sorry, I don't see anything obvious in the crash.
When the crash happens the compiler is looking up a name in a selector, as in x.m.  It
has decided that m is a method, but the type of x is not an interface, not a struct, and
does not have a name, and the same is true for *x.  That seems to cover all the cases,
so I don't know what I am missing.
Let me know if you are able to come up with a test case.

@alberts
Copy link
Contributor Author

alberts commented Dec 10, 2010

Comment 3:

Here's some info from gdb if that helps. Using r167678. Assert fails at line 7539 with
this revision.
(gdb) p m
$19 = (Method *) 0x0
m is null, which is why the assert fails.
(gdb) p nt
$17 = (const Named_type *) 0x14cb420
(gdb) p *nt
$18 = {<Type> = {_vptr.Type = 0xda1150, static type_trees =
std::tr1::unordered_map with 0 elements, classification_ = Type::TYPE_NAMED, tree_ =
0x0, type_descriptor_decl_ = 0x0}, named_object_ = 0x14c9530, in_function_ = 0x0,
  type_ = 0x14cb380, local_methods_ = 0x14cb5f0, all_methods_ = 0x0, interface_method_tables_ = 0x0, pointer_interface_method_tables_ = 0x0, location_ = 71064, named_tree_ = 0x0, is_visible_ = false, is_error_ = false, seen_ = false}
nt is not null, so nt->method_function(name, NULL) returned NULL.
(gdb) p name
$1 = "Uint16"
(gdb) backtrace
#0  Type::bind_field_or_method (gogo=0x1496050, type=<value optimized out>,
expr=0x14fc9b0, name="Uint16", location=113562) at
../../gcc/gcc/go/gofrontend/types.cc:7539
#1  0x00000000005312f3 in lower (this=0x7fffffffdfe0, pexpr=0x14fcb80) at
../../gcc/gcc/go/gofrontend/expressions.h:529
#2  expression (this=0x7fffffffdfe0, pexpr=0x14fcb80) at
../../gcc/gcc/go/gofrontend/gogo.cc:1241
#3  Lower_parse_tree::expression (this=0x7fffffffdfe0, pexpr=0x14fcb80) at
../../gcc/gcc/go/gofrontend/gogo.cc:1229
#4  0x0000000000507df6 in Expression::traverse (pexpr=<value optimized out>,
traverse=0x7fffffffdfe0) at ../../gcc/gcc/go/gofrontend/expressions.cc:109
#5  0x000000000051bbdd in Call_expression::do_traverse (this=0x14fcb70,
traverse=0x7fffffffdfe0) at ../../gcc/gcc/go/gofrontend/expressions.cc:7850
#6  0x00000000005312c6 in Lower_parse_tree::expression (this=0x7fffffffdfe0,
pexpr=0x14fcaa8) at ../../gcc/gcc/go/gofrontend/gogo.cc:1234
#7  0x0000000000507df6 in Expression::traverse (pexpr=<value optimized out>,
traverse=0x7fffffffdfe0) at ../../gcc/gcc/go/gofrontend/expressions.cc:109
#8  0x000000000050821d in Type_conversion_expression::do_traverse (this=0x14fca90,
traverse=0x7fffffffdfe0) at ../../gcc/gcc/go/gofrontend/expressions.cc:2819
#9  0x00000000005312c6 in Lower_parse_tree::expression (this=0x7fffffffdfe0,
pexpr=0x14fcad8) at ../../gcc/gcc/go/gofrontend/gogo.cc:1234
#10 0x0000000000507df6 in Expression::traverse (pexpr=<value optimized out>,
traverse=0x7fffffffdfe0) at ../../gcc/gcc/go/gofrontend/expressions.cc:109
#11 0x00000000005325b9 in Lower_parse_tree::statement (this=0x7fffffffdfe0,
block=0x14fabc0, pindex=0x7fffffffded8, sorig=0x14fcac0) at
../../gcc/gcc/go/gofrontend/gogo.cc:1203
#12 0x000000000055ce7e in Statement::traverse (this=0x14fcac0, block=<value optimized
out>, pindex=<value optimized out>, traverse=0x7fffffffdfe0) at
../../gcc/gcc/go/gofrontend/statements.cc:59
#13 0x0000000000532cea in Block::traverse (this=0x14fabc0, traverse=0x7fffffffdfe0) at
../../gcc/gcc/go/gofrontend/gogo.cc:3004
#14 0x0000000000532f5f in Function::traverse (this=<value optimized out>,
traverse=<value optimized out>) at ../../gcc/gcc/go/gofrontend/gogo.cc:2650
#15 0x0000000000536df8 in Lower_parse_tree::function (this=0x7fffffffdfe0, no=0x14fbb30)
at ../../gcc/gcc/go/gofrontend/gogo.cc:1189
#16 0x0000000000534ced in Bindings::traverse (this=0x149c0e0, traverse=0x7fffffffdfe0,
is_global=true) at ../../gcc/gcc/go/gofrontend/gogo.cc:4099
#17 0x0000000000534d71 in Gogo::traverse (this=0x1496050, traverse=0x7fffffffdfe0) at
../../gcc/gcc/go/gofrontend/gogo.cc:1066
#18 0x0000000000534e87 in Gogo::lower_parse_tree (this=<value optimized out>) at
../../gcc/gcc/go/gofrontend/gogo.cc:1256
#19 0x0000000000524f60 in go_parse_input_files (filenames=<value optimized out>,
filename_count=2, only_check_syntax=false, require_return_statement=true) at
../../gcc/gcc/go/gofrontend/go.cc:99
#20 0x0000000000830f18 in compile_file (argc=12, argv=0x7fffffffe2e8) at
../../gcc/gcc/toplev.c:579
#21 do_compile (argc=12, argv=0x7fffffffe2e8) at ../../gcc/gcc/toplev.c:1874
#22 toplev_main (argc=12, argv=0x7fffffffe2e8) at ../../gcc/gcc/toplev.c:1937
#23 0x0000003b6861ee7d in __libc_start_main () from /lib64/libc.so.6
#24 0x00000000004ff36d in _start ()

@ianlancetaylor
Copy link
Contributor

Comment 4:

Thanks; do you know if this code is invalid in some way, and, if so, could you
characterize the way in which it is invalid?

@alberts
Copy link
Contributor Author

alberts commented Dec 10, 2010

Comment 5:

I am compiling two files together.
If I compile only foo.go, I get:
foo.go:69:39: error: use of undefined type ‘YetAnotherType’
If I compile only bar.go, I get:
bar.go:8:7: error: import file ‘anInternalPackage’ not found
bar.go:31:16: error: expected package
bar.go:59:208: error: expected ‘,’ or ‘}’
bar.go:104:24: error: reference to undefined name ‘Something’
bar.go:121:2: error: expected map index on right hand side
bar.go:129:23: error: expected map index on left hand side
bar.go:121:2: error: invalid tuple definition
bar.go:71:27: error: type assertion only valid for interface types
bar.go:70:40: error: type assertion only valid for interface types
bar.go:103:40: error: type assertion only valid for interface types
bar.go:123:20: error: type assertion only valid for interface types
bar.go:16:17: error: use of undefined type ‘AnotherType’
bar.go:16:17: error: use of undefined type ‘AnotherType’
bar.go:14:18: error: use of undefined type ‘SomeType’
bar.go:16:17: error: use of undefined type ‘AnotherType’
bar.go:16:17: error: use of undefined type ‘AnotherType’
bar.go:16:17: error: use of undefined type ‘AnotherType’
bar.go:16:17: error: use of undefined type ‘AnotherType’
bar.go:16:17: error: use of undefined type ‘AnotherType’
bar.go:16:17: error: use of undefined type ‘AnotherType’
No crash with either file on its own. As soon as I pass foo.go and bar.go, I get:
bar.go:8:7: error: import file ‘anInternalPackage’ not found
bar.go:31:16: error: expected package
bar.go:59:208: error: expected ‘,’ or ‘}’
go1: internal compiler error: in bind_field_or_method, at go/gofrontend/types.cc:7539
Hope that helps.

@ianlancetaylor
Copy link
Contributor

Comment 6:

From the debugging you provided, the problem is that nt->local_methods_ != NULL but
nt->all_methods_ == NULL.  That should be impossible.
Can you print *nt->named_object_ ?  I'm curious whether this type is defined locally or
imported, and the package_ field should indicate that.

@ianlancetaylor
Copy link
Contributor

Comment 7:

Also can you print *nt->type_ ?

@alberts
Copy link
Contributor Author

alberts commented Dec 13, 2010

Comment 8:

(gdb) p nt->local_methods_
$2 = (Bindings *) 0x14cb5f0
(gdb) p nt->all_methods_
$3 = (Methods *) 0x0
(gdb) p *nt->named_object_
$4 = {name_ = ".libgo_encoding.binary.bigEndian", package_ = 0x14b2d20, classification_
= Named_object::NAMED_OBJECT_TYPE, u_ = {unknown_value = 0x14cb420, const_value =
0x14cb420, type_value = 0x14cb420, type_declaration = 0x14cb420,
    var_value = 0x14cb420, result_var_value = 0x14cb420, func_value = 0x14cb420, func_declaration_value = 0x14cb420, package_value = 0x14cb420}, tree_ = 0x0}
(gdb) p *nt->type_
$5 = {_vptr.Type = 0xda1150, static type_trees = std::tr1::unordered_map with 0
elements, classification_ = Type::TYPE_NAMED, tree_ = 0x0, type_descriptor_decl_ = 0x0}

@ianlancetaylor
Copy link
Contributor

Comment 9:

In the backtrace, the value of the location parameter at the point of the assertion is
113562.  In gdb you can "print expand_location(113562)".  That should show you the
exactly where in the input files the compiler is crashing.  Can you show me that point
and some of the surrounding lines?

@alberts
Copy link
Contributor Author

alberts commented Dec 14, 2010

Comment 10:

(gdb) print expand_location(113562)
$4 = {file = 0x7fffffffe610 "foo.go", line = 203, column = 36, sysp = 0 '\000'}
foo.go imports "encoding/binary".
The crash is happening near the start of a function:
type Port uint16
func ParseFrame(/*more params here*/ frame []byte) (/*stuff here*/, error os.Error) {
if len(frame) < FixedHeaderSize {
    error = os.NewError(...)
    return
}
/*line 203*/ srcPort = Port(binary.BigEndian.Uint16(frame[0:2]))
// more lines calling binary.BigEndian.Uint16 here

@alberts
Copy link
Contributor Author

alberts commented Dec 14, 2010

Comment 11:

I came up with the following stress test. It happens to reproduce this bug.
find $GOROOT -name '*.go' | xargs -n 1 -t gccgo -c > ~/gccgo.txt 2>&1
grep "internal compiler error" ~/gccgo.txt | sort -u
gccgo seems to hang on go/src/pkg/go/typechecker/testdata/test0.go, or take a really
long time.
gccgo: internal compiler error: Segmentation fault (program go1)
gccgo: internal compiler error: Terminated (program go1)
go1: internal compiler error: in bind_field_or_method, at go/gofrontend/types.cc:7539
go1: internal compiler error: in comparison_tree, at go/gofrontend/expressions.cc:5945
go1: internal compiler error: in comparison_tree, at go/gofrontend/expressions.cc:6111
go1: internal compiler error: in copy_parm_to_heap, at go/gofrontend/gogo-tree.cc:1463
go1: internal compiler error: in do_check_types, at go/gofrontend/statements.cc:353
go1: internal compiler error: in do_determine_type, at go/gofrontend/expressions.h:881
go1: internal compiler error: in do_get_init_tree, at go/gofrontend/types.cc:3771
go1: internal compiler error: in do_get_tree, at go/gofrontend/expressions.cc:10382
go1: internal compiler error: in do_get_tree, at go/gofrontend/expressions.cc:9611
go1: internal compiler error: in find_field_or_method, at go/gofrontend/types.cc:7671
go1: internal compiler error: in fold_binary_loc, at fold-const.c:9342
go1: internal compiler error: in make_receiver_parm_decl, at
go/gofrontend/gogo-tree.cc:1408
go1: internal compiler error: in Named_object, at go/gofrontend/gogo.cc:3488
go1: internal compiler error: Segmentation fault
go1: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in build_array_type_1, at tree.c:7235
go1: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in do_get_tree, at go/gofrontend/expressions.cc:9048
go1: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in do_get_tree, at go/gofrontend/expressions.cc:9093
go1: internal compiler error: tree check: expected tree that contains ‘decl common’
structure, have ‘error_mark’ in get_or_make_decl, at go/gofrontend/gogo-tree.cc:1317
/home/alberts/go/src/pkg/asn1/asn1_test.go:222:6: internal compiler error: tree check:
expected class ‘type’, have ‘exceptional’ (error_mark) in
useless_type_conversion_p, at tree-ssa.c:1251
/home/alberts/go/src/pkg/exp/draw/draw_test.go:148:6: internal compiler error: tree
check: expected class ‘type’, have ‘exceptional’ (error_mark) in
useless_type_conversion_p, at tree-ssa.c:1251
/home/alberts/go/src/pkg/exp/eval/eval_test.go:50:6: internal compiler error: tree
check: expected class ‘type’, have ‘exceptional’ (error_mark) in
useless_type_conversion_p, at tree-ssa.c:1251
/home/alberts/go/src/pkg/exp/eval/world.go:24:7: internal compiler error: Segmentation
fault
/home/alberts/go/src/pkg/goprotobuf.googlecode.com/hg/proto/all_test.go:1048:9: internal
compiler error: Segmentation fault
/home/alberts/go/src/pkg/json/decode.go:51:23: internal compiler error: Segmentation
fault

@alberts
Copy link
Contributor Author

alberts commented Dec 14, 2010

Comment 12:

Another bunch with a Python script that just feeds it random input based on files in
GOROOT:
go1: internal compiler error: in add_method_declaration, at go/gofrontend/types.cc:7926
go1: internal compiler error: in bind_field_or_method, at go/gofrontend/types.cc:7539
go1: internal compiler error: in create_tmp_var, at gimplify.c:465
go1: internal compiler error: in current_function, at go/gofrontend/gogo.cc:753
go1: internal compiler error: in do_check_types, at go/gofrontend/expressions.cc:7249
go1: internal compiler error: in do_check_types, at go/gofrontend/expressions.cc:8904
go1: internal compiler error: in do_check_types, at go/gofrontend/statements.cc:353
go1: internal compiler error: in do_determine_type, at go/gofrontend/expressions.h:881
go1: internal compiler error: in do_get_init_tree, at go/gofrontend/types.cc:3771
go1: internal compiler error: in do_get_tree, at go/gofrontend/expressions.cc:10382
go1: internal compiler error: in do_get_tree, at go/gofrontend/expressions.cc:3174
go1: internal compiler error: in find_field_or_method, at go/gofrontend/types.cc:7671
go1: internal compiler error: in function, at go/gofrontend/gogo.cc:2158
go1: internal compiler error: in gather_number, at go/gofrontend/lex.cc:1053
go1: internal compiler error: in get_fn_and_arg, at go/gofrontend/statements.cc:2231
go1: internal compiler error: in make_receiver_parm_decl, at
go/gofrontend/gogo-tree.cc:1408
go1: internal compiler error: in Named_object, at go/gofrontend/gogo.cc:3488
go1: internal compiler error: in swap_for_recover, at go/gofrontend/gogo.cc:2624
go1: internal compiler error: in type_declaration_value, at go/gofrontend/gogo.h:1670
go1: internal compiler error: Segmentation fault
go1: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in build_array_type_1, at tree.c:7235
go1: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in convert_to_integer, at convert.c:411
go1: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in do_get_tree, at go/gofrontend/expressions.cc:10044
go1: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in do_get_tree, at go/gofrontend/expressions.cc:11095
go1: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in do_get_tree, at go/gofrontend/expressions.cc:9048
go1: internal compiler error: tree check: expected tree that contains ‘decl common’
structure, have ‘error_mark’ in get_or_make_decl, at go/gofrontend/gogo-tree.cc:1317

Attachments:

  1. fuzzgc.py (1608 bytes)

@alberts
Copy link
Contributor Author

alberts commented Dec 16, 2010

Comment 13:

I see you've been making some great progress. The only remaining issue with files in
$GOROOT is:
gccgo -c $GOROOT/src/cmd/cgo/out.go
go1: internal compiler error: in do_check_types, at go/gofrontend/statements.cc:353
I also noticed:
$GOROOT/src/pkg/syscall/exec_windows.go:58:29: warning: invalid UTF-8 encoding [enabled
by default]
$GOROOT/test/string_lit.go:45:13: warning: invalid UTF-8 encoding [enabled by default]
$GOROOT/test/string_lit.go:110:13: warning: invalid UTF-8 encoding [enabled by default]
What's that about?
The random input still turns up quite a few issues. A slightly prettier fuzzgc.py
attached.
I also found some random input that causes an infinite loop somewhere. Attached.

Attachments:

  1. hang.zip (17467 bytes)
  2. fuzzgc.py (2004 bytes)

@ianlancetaylor
Copy link
Contributor

Comment 14:

The invalid UTF-8 encoding warnings come when converting a string constant to []int if
the string constant does not hold valid UTF-8.  The one in exec_windows.go was bogus,
and I fixed it.  The other warnings are valid.  They are only warnings because this is
not invalid Go, it's just probably not what the programmer really wants.

@alberts
Copy link
Contributor Author

alberts commented Dec 22, 2010

Comment 15:

Retested with r168163:
gccgo -c $GOROOT/src/cmd/cgo/out.go
In function ‘main.dynimport’:
go1: internal compiler error: in get_decl, at go/gofrontend/statements.h:492
gccgo -c $GOROOT/test/append.go
go1: internal compiler error: Segmentation fault

@alberts
Copy link
Contributor Author

alberts commented Dec 22, 2010

Comment 16:

Another minor issue turned up with:
find $GOROOT -name '*.go' | xargs -n 1 -t valgrind --leak-check=full -v
--trace-children=yes --track-origins=yes gccgo -c
==26726== 1 errors in context 1 of 51:
==26726== Conditional jump or move depends on uninitialised value(s)
==26726==    at 0x542141: Lex::require_line() (lex.cc:501)
==26726==    by 0x54435A: Lex::next_token() (lex.cc:544)
==26726==    by 0x544A42: Parse::peek_token() (parse.cc:64)
==26726==    by 0x54655A: Parse::package_clause() (parse.cc:4603)
==26726==    by 0x55366D: Parse::program() (parse.cc:4683)
==26726==    by 0x51D87C: go_parse_input_files (go.cc:82)
==26726==    by 0x82F1E7: toplev_main (toplev.c:579)
==26726==    by 0x37FFA1EE7C: (below main) (in /lib64/libc-2.12.90.so)
==26726==  Uninitialised value was created by a stack allocation
==26726==    at 0x51A520: go_langhook_parse_file (go-lang.c:275)
One file that reproduces this is $GOROOT/src/cmd/5c/doc.go.
I see various bits of GCC leak bytes here and there, but I guess nobody is too concerned
about that.

@ianlancetaylor
Copy link
Contributor

Comment 17:

Thanks for the test cases and scripts.  I've gotten your fuzzer script to run five times
without finding any crashes, so I'm declaring this bug closed.  Let's put any new
crashes in new bugs.  Thanks.

Status changed to Fixed.

@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants