Re: How to interpret (encoded?) gdb response

[Michael Snyder <msnyder@vmware.com>]

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.