Skip to content

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

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.

Sign up for GitHub

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

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

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

griesemer opened this issue Apr 10, 2014 · 4 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Gccgo

Comments

@griesemer
Copy link
Contributor 

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
Copy link
Member

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
Copy link
Contributor Author

Comment 2:

See also issue #7755.

@griesemer
Copy link
Contributor Author

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
Copy link
Member

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.

@rsc rsc added this to the Unplanned milestone Apr 10, 2015
@rsc rsc added Gccgo and removed release-none labels Apr 10, 2015
@rsc rsc modified the milestones: Gccgo, Unplanned Apr 15, 2015
@rsc rsc removed the Gccgo label Apr 15, 2015
@josharian josharian mentioned this issue Jul 17, 2016
Closed
@seankhliao seankhliao added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jul 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Gccgo
Development

No branches or pull requests
4 participants
@rsc @ianlancetaylor @griesemer @seankhliao