This is the mail archive of the
mailing list for the GDB project.
Re: How to interpret (encoded?) gdb response
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...