This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: How to interpret (encoded?) gdb response
- From: Michael Snyder <msnyder at vmware dot com>
- To: André Pönitz <apoenitz at trolltech dot com>
- Cc: "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Thu, 14 Aug 2008 09:23:09 -0700
- Subject: Re: How to interpret (encoded?) gdb response
- References: <200808141113.21141.apoenitz@trolltech.com>
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.