From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-32826-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 13537 invoked by alias); 14 Aug 2008 16:24:52 -0000
Received: (qmail 13520 invoked by uid 22791); 14 Aug 2008 16:24:48 -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; Thu, 14 Aug 2008 16:24:03 +0000
Received: from mailhost5.vmware.com (unknown [10.16.68.131]) 	by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 107606961; 	Thu, 14 Aug 2008 09:24:02 -0700 (PDT)
Received: from [10.20.92.47] (promb-2s-dhcp47.eng.vmware.com [10.20.92.47]) 	by mailhost5.vmware.com (Postfix) with ESMTP id 3FF0FDC07E; 	Thu, 14 Aug 2008 09:24:01 -0700 (PDT)
Message-ID: <48A45BED.3080606@vmware.com>
Date: Thu, 14 Aug 2008 20:39:00 -0000
From: Michael Snyder <msnyder@vmware.com>
User-Agent: Thunderbird 1.5.0.12 (X11/20080411)
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Andr=E9_P=F6nitz?= <apoenitz@trolltech.com>
CC: "gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: How to interpret (encoded?) gdb response
References: <200808141113.21141.apoenitz@trolltech.com>
In-Reply-To: <200808141113.21141.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: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2008-08/txt/msg00179.txt.bz2

André Pönitz wrote:
> Hi all.
> 
> I do the foillowing:
> 
>   - run an inferior containing a tight endless loop
>   - attach to it with gdb -pid=<id>
>   - run  'kill <pid>' 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"
> 
> Does that msg have any meaning, i.e. how would I "decode" it?
> The message appears also in a non-MI environment, but is even
> less legible there...

Here's the problem, I think ...

"kill <pid>" 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.

When gdb tries to resume the process, there's no process
there for it to talk to.