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

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:

  &"Cannot access memory at address 0x7fff6ca72a4c\n"
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.

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