Stack "signal handler called"

Stack "signal handler called"

[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?

Thanks

bye  Fabi

Re: Stack "signal handler called"

[Daniel Jacobowitz]

On Thu, Sep 30, 2004 at 11:45:46AM +0200, Fabian Cenedese wrote:
> 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

Re: Stack "signal handler called"

[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