http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24025
Jonathan Larmour <jifl-bugzilla at jifvik dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jifl-bugzilla at jifvik dot
| |org
--- Comment #11 from Jonathan Larmour <jifl-bugzilla at jifvik dot org>
2012-11-05 18:21:18 UTC ---
I'm quite surprised to find that this problem still exists in the current trunk
for platforms without TLS (i.e. many embedded platforms). Although I don't see
a recursive call but a rather more direct chain of events:
1) We completely run out of heap memory calling operator new. To see this
problem, less than the size of 'struct __cxa_eh_globals' must be available.
2) new throws std::bad_alloc, causing __cxa_allocate_exception to be called
3) __cxa_allocate_exception calls malloc() which still fails, but an emergency
buffer is available, so it is able to continue.
4) But __cxa_allocate_exception then calls __cxa_get_globals()
5) If __cxa_get_globals() has not been called before, it will allocate the
globals structure beginning with a call to malloc()
6) malloc() still fails, so std::terminate() is called.
The effect is that if std::bad_alloc is the first C++ exception this thread has
thrown, we can never catch it - instead the program is always abruptly
terminated, by default with abort(). This seems to be a surprisingly serious
issue given this is a 7 year old bug report.
Jifl
