Re: libSegFault and just in time debugging

["Michael Snyder" <msnyder at sonic dot net>]

----- Original Message ----- 
From: "Dave Korn" <dave.korn@artimi.com>
To: "'Michael Snyder'" <msnyder@sonic.net>; <gdb@sourceware.org>
Sent: Saturday, June 30, 2007 10:27 AM
Subject: RE: libSegFault and just in time debugging


> On 29 June 2007 20:11, Michael Snyder wrote:
>
> > What if, instead of doing that, libSegFault (or another similar library)
> > were to open a socket to a daemon and say "I caught a crash -- what
> > do you want me to do?".  And then wait for a reply.  All that can be
> > done with async-signal-safe function calls.
> >
> > The daemon, because it is NOT in a signal handler, can do anything
> > it wants, eg. open a GUI window and say "Program XYZ has crashed:
> > would you like to debug it?"  User clicks a button, daemon fires up
> > gdb, attaches to crashing program, then responds to the signal handler
> > library with a message saying "get out of the way, please...".  The
> > library removes itself from the signal vector, re-raises the signal,
> > and returns.  And gdb finds itself at the point where the signal was
> > originally raised.
>
>   Implementation-wise, wouldn't it be easier to just build a
mini-gdbserver[*]
> into libsegfault itself?

Maybe -- but how mini?  We're in a signal handler, so there are limits
to what we can do.  On the other hand, with the "real" gdbserver, or
gdb, we should be able to get the process back to virtually the state
that it was in when the signal occurred, and debug it as if it had been
running under the debugger all along.  Better than a core file...

On the other hand, I have been thinking that maybe gdbserver could
be the daemon...  then it could just fork itself and attach to the crashed
process.