Re: Gdb support for exceptions (Re: using backtrace() in exception throwing?)

Hi Tom,

On Tue, 2013-02-26 at 14:23 +0100, Jan Holesovsky wrote:
> > Michael> Even better than this would (perhaps) be a "break inside thrower that
> > Michael> is caught here" type breakpoint - that we could invoke to land us in
> > Michael> whatever code is going to throw as it does that [ and before it started
> > Michael> all the magic cleanup / unwinding work ]. That is - assuming that it's
> > Michael> possible for the code to know (at that point) where it will ultimately
> > Michael> end up (? ;-)
> >
> > I think it isn't possible in general.  When an exception is thrown, I
> > think all that can really be determined is the next catch point.

        This would be perfect. Explicit rethrows are relatively rare in our
code, however it is completely normal to have code that we simply don't
understand and/or follow - whereby we do:

A:
        try {
B:              do_incredibly_complex_thing();
        } catch (const uno::Exception &e) {
C:              ... flow eventually ends up here ...
        }

        Where by do_incredibly_complex_thing - it is expected that this method
dlopens a dozen separate shared libraries, does 1bn instructions or so -
and (somewhere in the middle) fails in some odd way - that we're trying
to find. Oh - of course, about two dozen+ 'expected' exceptions will get
thrown and caught during that process.

        Current approaches to trying to find: "what inside B threw to C"
involve: putting a break-point in 'A', then putting a breakpoint in
__cxa_throw - continuing, and typing 'continue <N>' several times to
work out what value of 'two dozen+' we have today, manually counting /
trying to binary chop towards that number: and finally we get near
enough that breaking on and carefully examining every exception in a
plausible range that may cause this issue.

        That flow as you can see is pretty hideous :-) what we really want to
do is:

        catch thrower-to-C

        or somesuch :-) being able to handle rethrows simply by re-starting gdb
and the app, doing a 'catch thrower-to-<rethrow-catch>' would be
blissful in comparison - walking up the chain one by one ;-)

> In other words - I'd love if gdb were able to do this even with the
> re-throw limitation :-)

        As kendy says this would really help us read, understand, unwind and
improve complex code.

Tom wrote:
> I also implemented a way to filter exception catches by name:
>
>    catch catch [REGEXP]
>    catch throw [REGEXP]
>    catch rethrow [REGEXP]

        This is really nice; the ability to hide many of the "two dozen+"
expected exceptions in some way be really useful. Unfortunately these
are often of quite generic types :-)

        Tor suggested on IRC some way of ignoring specific exception throwing
sites which tend to creep into the code over time and need tackling.
Some low-level technology will decide it's better to fire an Exception
than return an undefined value of some kind - and suddenly two-dozen+
turns into 100's - (I just got this today) ;-)

        Being able to say: catch throw ignore - which would ignore the last
thrown exception site would be really lovely ;-)

        Is any of that useful ? - really looking forward to getting a new
libstdc++ etc. with your fixes in a few months :-)

        Thanks !

                Michael.

-- 
michael.meeks@suse.com  <><, Pseudo Engineer, itinerant idiot