Re: How to interpret (encoded?) gdb response

Michael Snyder
2008-08-15T18:24:46Z

AndrÃ© PÃ¶nitz wrote:
> 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...

I agree, I think gdb could probably be more proactive
about detecting that the ptraced process has disappeared
while we waited at the prompt.