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