From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3294 invoked by alias); 29 Jun 2007 19:10:23 -0000 Received: (qmail 3281 invoked by uid 22791); 29 Jun 2007 19:10:22 -0000 X-Spam-Check-By: sourceware.org Received: from a.mail.sonic.net (HELO a.mail.sonic.net) (64.142.16.245) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 29 Jun 2007 19:10:20 +0000 Received: from snyder (209-204-172-156.dsl.dynamic.sonic.net [209.204.172.156]) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with SMTP id l5TJAIHh026409 for ; Fri, 29 Jun 2007 12:10:18 -0700 Message-ID: <003c01c7ba81$2abc9ce0$677ba8c0@sonic.net> Reply-To: "Michael Snyder" From: "Michael Snyder" To: Subject: libSegFault and just in time debugging Date: Fri, 29 Jun 2007 19:10:00 -0000 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-06/txt/msg00345.txt.bz2 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?