Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: "Michael Snyder" <msnyder@sonic.net>
To: <gdb@sourceware.org>
Subject: libSegFault and just in time debugging
Date: Fri, 29 Jun 2007 19:10:00 -0000	[thread overview]
Message-ID: <003c01c7ba81$2abc9ce0$677ba8c0@sonic.net> (raw)

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
originally raised.

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.

Interesting?



             reply	other threads:[~2007-06-29 19:10 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-29 19:10 Michael Snyder [this message]
2007-06-29 19:15 ` Daniel Jacobowitz
2007-06-29 19:52   ` Michael Snyder
2007-06-29 20:00     ` Daniel Jacobowitz
2007-06-29 20:12       ` Jim Ingham
2007-06-29 20:14         ` Jim Ingham
2007-06-29 20:24           ` Michael Snyder
2007-06-29 20:20         ` Michael Snyder
2007-06-30 10:52       ` Eli Zaretskii
2007-06-30 11:49         ` Eli Zaretskii
2007-06-30 15:49         ` Daniel Jacobowitz
2007-06-30 16:03           ` Michael Snyder
2007-06-30 16:10             ` Mark Kettenis
2007-06-30 18:22             ` Eli Zaretskii
2007-06-30 18:19           ` Eli Zaretskii
2007-06-30 17:28 ` Dave Korn
2007-06-30 21:27   ` Michael Snyder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='003c01c7ba81$2abc9ce0$677ba8c0@sonic.net' \
    --to=msnyder@sonic.net \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox