Re: How to interpret (encoded?) gdb response

[André Pönitz <apoenitz at trolltech dot com>]

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é