This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]