On Fri, May 27, 2005 at 08:29:03AM -0600, Patrick Walsh wrote:
> 	Another day, another Signal 11.  On the machine running the latest
> patches and versions, we have these logs:

> [ W(327) : 0000 : 00:30:01 ] *****  FATAL SIGNAL (11) *****
> 00:30:01 Fatal Signal (11); pid 25080 becoming a zombie...
> 00:30:01 You may use gdb to attach to 25080
> 
> 	And this gdb trace:
> 
> 0xb73f79d6 in __sigsuspend (set=0x159250fc)
>     at ../sysdeps/unix/sysv/linux/sigsuspend.c:45
> 45      ../sysdeps/unix/sysv/linux/sigsuspend.c: No such file or
> directory.
> ---Type <return> to continue, or q <return> to quit---
>         in ../sysdeps/unix/sysv/linux/sigsuspend.c
> (gdb) bt
> #0  0xb73f79d6 in __sigsuspend (set=0x159250fc)
>     at ../sysdeps/unix/sysv/linux/sigsuspend.c:45
> #1  0x080ab4b1 in strcpy () at ../sysdeps/generic/strcpy.c:31
> #2  <signal handler called>
> #3  0x0804e53c in strcpy () at ../sysdeps/generic/strcpy.c:31
> #4  0x0c319ef8 in ?? ()
> #5  0x080ac414 in strcpy () at ../sysdeps/generic/strcpy.c:31
> #6  0x080ac0e8 in strcpy () at ../sysdeps/generic/strcpy.c:31

Still no debug symbols in the binary, that's kind of annoying. Also,
this trace looks suspiciously similar to the previous ones so we're
probably looking at the same bug. Which means that the one I found
wasn't actually triggered in your case.

That jump from 0x08 to 0x0c and then back to 0x08 looks a lot like we
called a library function which then called a callback in the main
program.

Jan