From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24509 invoked by alias); 30 Jun 2007 21:27:58 -0000 Received: (qmail 24490 invoked by uid 22791); 30 Jun 2007 21:27:58 -0000 X-Spam-Check-By: sourceware.org Received: from b.mail.sonic.net (HELO b.mail.sonic.net) (64.142.19.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 30 Jun 2007 21:27:55 +0000 Received: from snyder (209-204-172-156.dsl.dynamic.sonic.net [209.204.172.156]) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with SMTP id l5ULRo1H010949; Sat, 30 Jun 2007 14:27:51 -0700 Message-ID: <000701c7bb5d$8a530e00$677ba8c0@sonic.net> Reply-To: "Michael Snyder" From: "Michael Snyder" To: "Dave Korn" , References: <003c01c7ba81$2abc9ce0$677ba8c0@sonic.net> <007601c7bb3b$dde90910$2e08a8c0@CAM.ARTIMI.COM> Subject: Re: libSegFault and just in time debugging Date: Sat, 30 Jun 2007 21:27: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/msg00363.txt.bz2 ----- Original Message ----- From: "Dave Korn" To: "'Michael Snyder'" ; 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.