Discussion:
Stack "signal handler called"
Fabian Cenedese
2004-09-30 09:45:46 UTC
Permalink
Hi

I tried to examine a target where a thread had crashed. I issued bt
and got only one frame, somewhere in memcpy.c. For the second
frame gdb only printed <signal handler called>. What does this mean?
I found the string in stack.c but I couldn't make out the meaning.
Does it mean that the call stack was destroyed? Some invalid
addresses in the call stack?

Thanks

bye Fabi
Daniel Jacobowitz
2004-10-03 18:42:30 UTC
Permalink
Post by Fabian Cenedese
Hi
I tried to examine a target where a thread had crashed. I issued bt
and got only one frame, somewhere in memcpy.c. For the second
frame gdb only printed <signal handler called>. What does this mean?
I found the string in stack.c but I couldn't make out the meaning.
Does it mean that the call stack was destroyed? Some invalid
addresses in the call stack?
It means that GDB thinks that a signal handler has been invoked, and
that the frames above it are in the signal handler context. If that's
incorrect, you've found a bug in GDB.

(You mentioned threads. It may be that the application is placing
thread stacks in such a way that GDB is confused...)
--
Daniel Jacobowitz
Fabian Cenedese
2004-10-04 08:59:46 UTC
Permalink
Post by Daniel Jacobowitz
Post by Fabian Cenedese
I tried to examine a target where a thread had crashed. I issued bt
and got only one frame, somewhere in memcpy.c. For the second
frame gdb only printed <signal handler called>. What does this mean?
I found the string in stack.c but I couldn't make out the meaning.
Does it mean that the call stack was destroyed? Some invalid
addresses in the call stack?
It means that GDB thinks that a signal handler has been invoked, and
that the frames above it are in the signal handler context. If that's
incorrect, you've found a bug in GDB.
(You mentioned threads. It may be that the application is placing
thread stacks in such a way that GDB is confused...)
There are some possibilities for errors on our side. The callstack could
be made up wrong in case of a trap, and our debugger could also read
and interpret wrong data. But it usually works fine. As it didn't work
in this case I tried if gdb could perform better. As it didn't get further
either I'll assume for now that there really was an error in the call stack.
More investigations didn't reveal anything.

Thanks

bye Fabi

Loading...