On Tue, May 28, 2013 at 9:16 PM, Ryan Johnson <ryan.john...@cs.utoronto.ca> wrote: > On 29/05/2013 12:01 AM, Ian Lance Taylor wrote: >> >> On Tue, May 28, 2013 at 8:50 PM, Ryan Johnson >> <ryan.john...@cs.utoronto.ca> wrote: >>> >>> For example, it should be reasonably safe to let __cxa_allocate_exception >>> call dl_iterate_phdr in order to build a list of object headers valid at >>> the >>> time unwind begins. It already calls malloc, so allocating space for a >>> cache >>> (holding pointers to at most a few dozen object headers) wouldn't be so >>> terrible; __cxa_free_exception could release the space after the dust >>> settles. In order to optimize non-throw uses of unwinding, it might make >>> sense to build the cache somewhere besides __cxa_allocate_exception, but >>> the >>> basic concept doesn't change. >> >> Actually, when everything is working correctly with modern tools on a >> GNU/Linux system, the unwind code never calls malloc. That is a good >> thing, as otherwise it would be unsafe to throw from a signal handler. > > Hmm... How recent is "modern" ? Because the only obvious > __cxa_allocate_exception in the gcc-4.8 sources > (libstdc++-v3/libsupc++/eh_alloc.cc) sure seems to call malloc, and the > traces I got from throwing in code compiled by both gcc-4.6 and gcc-4.8 > (gold linker) show calls to malloc as well.
Sorry, you're quite right. I've gotten out of the habit of thinking of C++. The unwind code does not call malloc, and that is important. But actually throwing an exception from C++ does call malloc, and that is problematic when trying to throw from a signal handler. I shouldn't have used that as an example. It's important that the unwind code proper does not call malloc so that we can reliably get stack traces from signal handlers, specifically from the SIGPROF signal. Ian
