From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7577 invoked by alias); 15 Aug 2008 18:24:46 -0000 Received: (qmail 7567 invoked by uid 22791); 15 Aug 2008 18:24:46 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.113.40.141) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 15 Aug 2008 18:23:56 +0000 Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.64.160]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 32A40683D; Fri, 15 Aug 2008 11:23:54 -0700 (PDT) Received: from [10.20.92.47] (promb-2s-dhcp47.eng.vmware.com [10.20.92.47]) by mailhost2.vmware.com (Postfix) with ESMTP id 3DBC83C123; Fri, 15 Aug 2008 11:23:54 -0700 (PDT) Message-ID: <48A5C98F.9080000@vmware.com> Date: Fri, 15 Aug 2008 23:28:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Andr=E9_P=F6nitz?= CC: "gdb@sourceware.org" Subject: Re: How to interpret (encoded?) gdb response References: <200808141113.21141.apoenitz@trolltech.com> <48A45BED.3080606@vmware.com> <200808151009.30158.apoenitz@trolltech.com> In-Reply-To: <200808151009.30158.apoenitz@trolltech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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/msg00191.txt.bz2 André Pönitz wrote: > On Thursday 14 August 2008 18:23:09 Michael Snyder wrote: >> André Pönitz wrote: >>> [...] >>> - run an inferior containing a tight endless loop >>> - attach to it with gdb -pid= >>> - run 'kill ' in shell >>> - do -exec-continue >>> >>> then I get: >>> >>> 67^running >>> (gdb) >>> &"Cannot access memory at address 0x7fff6ca72a4c\n" >>> &"\240\240\354\003\n" >>> 67^error,msg="\240\240\354\003" >>> [...] >> Here's the problem, I think ... >> >> "kill " without a signal value defaults to SIGKILL, >> which cannot be intercepted or differed. That means that >> the process goes away "right now". >> >> 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 > 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 > message would contain some information on what happened, but > Daniel's suspicion of a bad pointer seems to be right... I agree, I think gdb could probably be more proactive about detecting that the ptraced process has disappeared while we waited at the prompt.