How to interpret (encoded?) gdb response

How to interpret (encoded?) gdb response

[André Pönitz]

Hi all.

I do the foillowing:

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

Does that msg have any meaning, i.e. how would I "decode" it?
The message appears also in a non-MI environment, but is even
less legible there...

Regards,
André

Re: How to interpret (encoded?) gdb response

[Daniel Jacobowitz]

On Thu, Aug 14, 2008 at 11:13:08AM +0200, Andr? P?nitz wrote:
> 
> Hi all.
> 
> I do the foillowing:
> 
>   - 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"
> 
> Does that msg have any meaning, i.e. how would I "decode" it?
> The message appears also in a non-MI environment, but is even
> less legible there...

No, it's some sort of bug or bad pointer.  Does this happen in HEAD?

-- 
Daniel Jacobowitz
CodeSourcery

Re: How to interpret (encoded?) gdb response

[Michael Snyder]

André Pönitz wrote:
> Hi all.
> 
> I do the foillowing:
> 
>   - 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"
> 
> Does that msg have any meaning, i.e. how would I "decode" it?
> The message appears also in a non-MI environment, but is even
> less legible there...

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.

When gdb tries to resume the process, there's no process
there for it to talk to.

Re: How to interpret (encoded?) gdb response

[Daniel Jacobowitz]

On Thu, Aug 14, 2008 at 09:23:09AM -0700, Michael Snyder wrote:
> "kill <pid>" without a signal value defaults to SIGKILL,
> which cannot be intercepted or differed.  That means that
> the process goes away "right now".

No, it doesn't.  kill is SIGTERM.

-- 
Daniel Jacobowitz
CodeSourcery

Re: How to interpret (encoded?) gdb response

[André Pönitz]

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é

Re: How to interpret (encoded?) gdb response

[Michael Snyder]

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.