This is the mail archive of the
mailing list for the GDB project.
libSegFault and just in time debugging
- From: "Michael Snyder" <msnyder at sonic dot net>
- To: <gdb at sourceware dot org>
- Date: Fri, 29 Jun 2007 12:10:32 -0700
- Subject: libSegFault and just in time debugging
- Reply-to: "Michael Snyder" <msnyder at sonic dot net>
Got an idea to pass in front of you...
If you don't know how libSegFault works, it is a dynamic library that
comes packaged with glibc. To use it, you get the runtime loader to
preload it and link it to your programs, using either the environment
variable LD_PRELOAD or the file /etc/ld.so.preload. Upon loading,
it takes over the signal handling vectors for half a dozen fatal signals
(SEGV, BUS, ILL, FPU...), but it does so *before* the main user program
is invoked -- so there's no interferance with programs that want to use
those vectors themselves. If the program *doesn't* handle the signal,
then libSegFault catches it and prints some useful debugging info to
the system console or syslog (before passing the signal back to the
kernel so that a core file can be generated).
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
If the user doesn't want to debug it, the daemon can tell the library
to just let it crash, or to log the information a la libSegFault, or
any number of other things.