From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25170 invoked by alias); 15 Aug 2008 08:06:57 -0000 Received: (qmail 25157 invoked by uid 22791); 15 Aug 2008 08:06:55 -0000 X-Spam-Check-By: sourceware.org Received: from hoat.troll.no (HELO hoat.troll.no) (62.70.27.150) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 15 Aug 2008 08:06:16 +0000 Received: from hoat.troll.no (tedur.troll.no [62.70.27.154]) by hoat.troll.no (Postfix) with SMTP id DE15120B8B for ; Fri, 15 Aug 2008 10:06:10 +0200 (CEST) Received: from gar.trolltech.de (gar.trolltech.de [10.4.0.24]) by hoat.troll.no (Postfix) with ESMTP id C4C74209AE for ; Fri, 15 Aug 2008 10:06:10 +0200 (CEST) From: =?iso-8859-1?q?Andr=E9_P=F6nitz?= To: gdb@sourceware.org Subject: Re: How to interpret (encoded?) gdb response Date: Fri, 15 Aug 2008 15:59:00 -0000 User-Agent: KMail/1.9.9 References: <200808141113.21141.apoenitz@trolltech.com> <48A45BED.3080606@vmware.com> In-Reply-To: <48A45BED.3080606@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200808151009.30158.apoenitz@trolltech.com> X-IsSubscribed: yes 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: 2008-08/txt/msg00185.txt.bz2 On Thursday 14 August 2008 18:23:09 Michael Snyder wrote: > Andr=E9 P=F6nitz wrote: > > [...] > > - run an inferior containing a tight endless loop > > - attach to it with gdb -pid=3D > > - run 'kill ' in shell > > - do -exec-continue > >=20 > > then I get: > >=20 > > 67^running > > (gdb) > > &"Cannot access memory at address 0x7fff6ca72a4c\n" > > &"\240\240\354\003\n" > > 67^error,msg=3D"\240\240\354\003" > > [...] >=20 > Here's the problem, I think ... >=20 > "kill " without a signal value defaults to SIGKILL, > which cannot be intercepted or differed. That means that > the process goes away "right now". >=20 > GDB, however, is sitting at the user prompt, thinking > that the process is not running. We're not expecting > the process to get signals when it's not running. I understand that I am doing "something nasty". But that was the result of stripping down some (largish) real world example. In a=20 multitasking environment sometimes "nasty" things like sending signals to processes happen behind the scenes and I'd like to be able to handle such cases gracefully ;-} Of course, gdb cannot do much if the process is gone, and it nicely flags an error. I was just assuming that the accompanying error=20 message would contain some information on what happened, but Daniel's suspicion of a bad pointer seems to be right... Regards, Andr=E9