Re: How to interpret (encoded?) gdb response

André Pönitz
2008-08-15T08:06:57Z

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=<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"
> > [...]
>
> 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.

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...

Regards,
André