https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
--- Comment #18 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 27 Jan 2015, redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535 > > --- Comment #17 from Jonathan Wakely <redi at gcc dot gnu.org> --- Ah, I > assumed the lack of destructor was intentional, so we can still deal > with exceptions while destroying globals. Otherwise an exception could > try to allocate from the pool after the destructor has run. Well - technically accessing emergency_pool after its default destructor ran is undefined (though we don't seem to run any destructor on it... I wonder if we do for __scoped_lock and if that works). I hope that initialization/destruction order imposed by some means allows EH to be thrown during initialization or destruction (though what would catch that?) We can make the patch safer by using pool::~pool () { __gnu_cxx::__scoped_lock sentry(emergency_mutex); free (arena); arena = NULL; } and/or by attaching a init_priority to the class. But again - where can you catch exceptions thrown from global initializers / destructors? If I throw from a __thread global constructor will the parent process be able to catch that exception somehow?
