Re: How to interpret (encoded?) gdb response

[Michael Snyder <msnyder@vmware.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.