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

gccgo: crash due to running out of memory (likely) #7754

Open
griesemer opened this issue Apr 10, 2014 · 4 comments

Comments

@griesemer
Copy link
Contributor

commented Apr 10, 2014

Test case: http://play.golang.org/p/xoT0jSBOci

Perhaps it's possible to give a nicer error message.

$ gccgo overflow.go 
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
go1: internal compiler error: Aborted
0x99a9ef crash_signal
    /tmp/go-build-release/gccgo-srcdir/gcc/toplev.c:337
0x1063bbc __gnu_cxx::__verbose_terminate_handler()
    /usr/crosstool/v15/gcc-4.6.x-glibc-2.11.1-grte/x86/debug-src/gcc-4_6/libstdc++-v3/libsupc++/vterminate.cc:95
0x10628f5 __cxxabiv1::__terminate(void (*)())
    /usr/crosstool/v15/gcc-4.6.x-glibc-2.11.1-grte/x86/debug-src/gcc-4_6/libstdc++-v3/libsupc++/eh_terminate.cc:40
0x1062922 std::terminate()
    /usr/crosstool/v15/gcc-4.6.x-glibc-2.11.1-grte/x86/debug-src/gcc-4_6/libstdc++-v3/libsupc++/eh_terminate.cc:50
0x1062a55 __cxa_throw
    /usr/crosstool/v15/gcc-4.6.x-glibc-2.11.1-grte/x86/debug-src/gcc-4_6/libstdc++-v3/libsupc++/eh_throw.cc:83
0x1062cfc operator new(unsigned long)
    /usr/crosstool/v15/gcc-4.6.x-glibc-2.11.1-grte/x86/debug-src/gcc-4_6/libstdc++-v3/libsupc++/new_op.cc:58
0x104be58 __gnu_cxx::new_allocator<char>::allocate(unsigned long, void const*)
    /usr/crosstool/v15/gcc-4.6.x-glibc-2.11.1-grte/x86/debug-src/build-gcc/x86_64-unknown-linux-gnu/libstdc++-v3/include/ext/new_allocator.h:92
0x104be58 std::basic_string<char, std::char_traits<char>,
std::allocator<char> >::_Rep::_S_create(unsigned long, unsigned long,
std::allocator<char> const&)
    /usr/crosstool/v15/gcc-4.6.x-glibc-2.11.1-grte/x86/debug-src/build-gcc/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:609
0x104cb3a std::basic_string<char, std::char_traits<char>,
std::allocator<char> >::_Rep::_M_clone(std::allocator<char> const&,
unsigned long)
    /usr/crosstool/v15/gcc-4.6.x-glibc-2.11.1-grte/x86/debug-src/build-gcc/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:631
0x104cc1f std::basic_string<char, std::char_traits<char>,
std::allocator<char> >::reserve(unsigned long)
    /usr/crosstool/v15/gcc-4.6.x-glibc-2.11.1-grte/x86/debug-src/build-gcc/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:512
0x104cc1f std::basic_string<char, std::char_traits<char>,
std::allocator<char> >::reserve(unsigned long)
    /usr/crosstool/v15/gcc-4.6.x-glibc-2.11.1-grte/x86/debug-src/build-gcc/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:503
0x104d11c std::basic_string<char, std::char_traits<char>,
std::allocator<char> >::append(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&)
    /usr/crosstool/v15/gcc-4.6.x-glibc-2.11.1-grte/x86/debug-src/build-gcc/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:334
0x56ddfd operator+<char, std::char_traits<char>, std::allocator<char> >
    /google/src/files/34541112/depot/google3/third_party/crosstool/v15/release/wrappers/x86/bin/../../../gcc/x86/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.x-google/../../../../include/c++/4.6.x-google/bits/basic_string.h:2310
0x56ddfd Binary_expression::do_lower(Gogo*, Named_object*, Statement_inserter*, int)
    /tmp/go-build-release/gccgo-srcdir/gcc/go/gofrontend/expressions.cc:5327
0x5914ae Expression::lower(Gogo*, Named_object*, Statement_inserter*, int)
    /tmp/go-build-release/gccgo-srcdir/gcc/go/gofrontend/expressions.h:623
0x5914ae Lower_parse_tree::expression(Expression**)
    /tmp/go-build-release/gccgo-srcdir/gcc/go/gofrontend/gogo.cc:1715
0x5914ae Lower_parse_tree::expression(Expression**)
    /tmp/go-build-release/gccgo-srcdir/gcc/go/gofrontend/gogo.cc:1703
0x559595 Expression::traverse(Expression**, Traverse*)
    /tmp/go-build-release/gccgo-srcdir/gcc/go/gofrontend/expressions.cc:54
0x59151c Named_constant::traverse_expression(Traverse*)
    /tmp/go-build-release/gccgo-srcdir/gcc/go/gofrontend/gogo.cc:4992
0x59151c Lower_parse_tree::constant(Named_object*, bool)
    /tmp/go-build-release/gccgo-srcdir/gcc/go/gofrontend/gogo.cc:1624
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://go.ext.google.com/go/>; for instructions.
@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Apr 10, 2014

Comment 1:

This is an interesting one, because the spec doesn't permit any other result.  We have
implementation restrictions on the sizes of numeric values, but we don't have any on the
sizes of string values.
What should we say is the minimum length of the longest string that an implementation
must permit?

Status changed to Accepted.

@griesemer

This comment has been minimized.

Copy link
Contributor Author

commented Apr 10, 2014

Comment 2:

See also issue #7755.
@griesemer

This comment has been minimized.

Copy link
Contributor Author

commented Apr 10, 2014

Comment 3:

I think any limit is going to be problematic: If one limits the size of an individual
string (say 1MB), one can simply create a lot of them (say 1000 1MB strings). A large
limit may be a problem on small devices. A small limit may cause legitimate problems
with some specialized codes.
I don't think we should enshrine any specific limit; I would be happy if the compiler
would not crash and instead report an "out of memory" error.
(We have the same problem with large numeric constants, even though we have a limit).
@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Apr 11, 2014

Comment 4:

Just waiting until the compiler runs out of memory is also not good behaviour, because
it means that the compiler eats up all of virtual memory, starving the machine.  Or, you
put an artificial limit on the amount of memory the compiler can use, but then you fail
to compile large programs that could be compiled, and it's painful to portably adapt to
machines with more available memory.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.