using backtrace() in exception throwing?

[Lubos Lunak]

On Sunday 17 of February 2013, Noel Grandin wrote:
> Hi
>
> Background: I'm looking at bug reports, and the messages are generally only
> marginally useful, because I generally have no idea where the original
> exception was actually thrown from.
> Sometimes the message in the exception will narrow it down a little, but
> that still often leaves a lot of likely places, and often the information
> I'm really interested in, is a few frames worth of callng stack
> information.
>
> What would be the costs of calling backtrace()
>    http://www.gnu.org/software/libc/manual/html_node/Backtraces.html
> in the exception base class, storing a few frames worth of data,
> and then modifying the exception printing code to call
>   backtrace_symbols()
> when writing out the exception?
>
> For me personally, this would really speed up tracking down the source of
> bugs.

 This could be very useful ('catch throw' is so cumbersome in gdb), but I 
think the first thing to check is if it would actually work. Last time I 
checked, "recent" features like -fvisibility make backtrace() very often 
generate call traces that are next to useless.

 If it turns out the data actually is useful, then also

- you can't simply modify the Exception base class, because it's part of the 
URE, so it should stay binary compatible. It'd need to be stored in the 
message (which is a question if it's a good or bad idea) or some other way 
would need to be found.

- it'd be good to know how fast/slow the function is. Exceptions generally 
aren't very fast, but if the function was called every time in the ctor, then 
depending on fast it is that might make it debug-build-only feature.

-- 
 Lubos Lunak
 l.lunak at suse.cz