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

Hi Tom,

On Wed, 2013-02-20 at 14:28 -0700, Tom Tromey wrote:
> FWIW we have the same problem in reverse: the gdb group at Red Hat is,
> among other things, tasked with improving the C++ debugging experience.
> However, most of us don't actually debug C++ programs on a regular
> basis.  We do know some issues, via bugzilla and other discussions, but
> I feel sure we are also missing things.

        Oh wow :-) so Lubos' feedback here is really great; personally I feel
like rather an inadequate gdb user myself ;-)

> Solving this in general looks tricky to me.  I am not really sure how to
> do it, but I will think about it some more.

        The basic debugging experience in these "an exception broke something"
flows is that we get an exception thrown that ultimately ends up in a
pathalogical situation - an abort, or some similar horrible badness. At
that point the most interesting thing is not the catcher - which usually
ends up being utterly random - but the last guy that threw the
exception. So then as Lubos says comes the knotty job of trying to put a
breakpoint on the -one- exception that ends up being caught where we are
now [ and that of course requires re-running, and inevitably we throw
dozens of exceptions in the normal case ].

> Meanwhile, I did whip up a quick-and-dirty Python-based approach.  It
> adds a new "track-throws" command.  This command installs a breakpoint
> that records the point of the most recent "throw".  Then you can examine
> the result with "info last-throw".

        This of course goes a huge way to solving the above problem :-)

        Really nice ! though of course - having a full stack trace would make
that very substantially more useful.

        Even better than this would (perhaps) be a "break inside thrower that
is caught here" type breakpoint - that we could invoke to land us in
whatever code is going to throw as it does that [ and before it started
all the magic cleanup / unwinding work ]. That is - assuming that it's
possible for the code to know (at that point) where it will ultimately
end up (? ;-)

        Anyhow - it's great to have some python help here; I guess we could
bundle that into our existing grab-bag of nice python fixes today :-)

        Thanks !

                Michael.

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