public inbox for libc-hacker@sourceware.org
 help / color / mirror / Atom feed
* 2.2.x mips signal crash
@ 2002-10-31 11:57 Jes Sorensen
  2002-10-31 18:44 ` H. J. Lu
  0 siblings, 1 reply; 3+ messages in thread
From: Jes Sorensen @ 2002-10-31 11:57 UTC (permalink / raw)
  To: libc-hacker

Hi

We are chasing a problem on Linux/mips with glibc-2.2.x, which I am not
sure whether is a kernel bug or a libc bug. We haven't been able to
reproduce it under Linux/x86 or Linux/ia64 so far though.

Basically what seems to be happening is the following, a task is
spawned from fork(), the child sends some signals to the parent after
which it exits.

The parent exits before the signals arrives and a signal is delivered
some time after reaching exit(). As the signal handler is using
printf() we get an explosion since the file descriptor seems to be
gone (munmap()).

My question is as follows: Is one required to wait for signal delivery
in the parent before exiting or unregister the signal handlers? or is
it a genuine bug?

Any suggestions?

Thanks,
Jes

The backtrace I get looks like this:

Program received signal SIGSEGV, Segmentation fault.
_wordcopy_fwd_aligned (dstp=715816944, srcp=2147439180, len=8)
    at ../sysdeps/generic/wordcopy.c:110
110	      ((op_t *) dstp)[4] = a1;
(gdb) bt
#0  _wordcopy_fwd_aligned (dstp=715816944, srcp=2147439180, len=8)
    at ../sysdeps/generic/wordcopy.c:110
#1  0x0043416c in __mempcpy (dstpp=0x2aaa7ff0, srcpp=0x7fff524c, len=22)
    at ../sysdeps/generic/mempcpy.c:57
#2  0x004309e4 in _IO_new_file_xsputn (f=0x10001070, data=0x7fff524c, n=22)
    at fileops.c:941
#3  0x00419b20 in buffered_vfprintf (s=0x10001070, format=0x7fff524c "", 
    args=0x8) at vfprintf.c:2104
#4  0x0041362c in _IO_vfprintf (s=0x10001070, 
    format=0x475584 "pid=%d usr2handler\n", ap=0x7fff792c) at vfprintf.c:1272
#5  0x00400aa0 in printf (format=0x7fff524c "") at printf.c:33
#6  0x00400528 in usr2handler ()
#7  <signal handler called>
#8  0x00409ee4 in munmap ()
#9  0x00431d98 in _IO_setb (f=0x10001070, b=0x100010b7 "", 
    eb=0x100010b8 "\020", a=Cannot access memory at address 0x0
) at genops.c:388
#10 0x00432308 in _IO_default_setbuf (fp=Cannot access memory at address 0x0
) at genops.c:548
#11 0x0042f690 in _IO_new_file_setbuf (fp=Cannot access memory at address 0x0
) at fileops.c:417
#12 0x00432fac in _IO_unbuffer_write () at genops.c:904
#13 0x00433038 in _IO_cleanup () at genops.c:924
#14 0x00401490 in exit (status=Cannot access memory at address 0x0
) at exit.c:74
#15 0x00400c94 in __libc_start_main (main=Cannot access memory at address 0x0
)
    at ../sysdeps/generic/libc-start.c:129

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: 2.2.x mips signal crash
  2002-10-31 11:57 2.2.x mips signal crash Jes Sorensen
@ 2002-10-31 18:44 ` H. J. Lu
       [not found]   ` <m37kfyvwin.fsf@trained-monkey.org>
  0 siblings, 1 reply; 3+ messages in thread
From: H. J. Lu @ 2002-10-31 18:44 UTC (permalink / raw)
  To: Jes Sorensen; +Cc: libc-hacker

On Thu, Oct 31, 2002 at 02:50:28PM -0500, Jes Sorensen wrote:
> Hi
> 
> We are chasing a problem on Linux/mips with glibc-2.2.x, which I am not
> sure whether is a kernel bug or a libc bug. We haven't been able to
> reproduce it under Linux/x86 or Linux/ia64 so far though.
> 
> Basically what seems to be happening is the following, a task is
> spawned from fork(), the child sends some signals to the parent after
> which it exits.
> 
> The parent exits before the signals arrives and a signal is delivered
> some time after reaching exit(). As the signal handler is using
> printf() we get an explosion since the file descriptor seems to be
> gone (munmap()).
> 
> My question is as follows: Is one required to wait for signal delivery
> in the parent before exiting or unregister the signal handlers? or is
> it a genuine bug?
> 
> Any suggestions?
> 

A testcase?


H.J.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: 2.2.x mips signal crash
       [not found]   ` <m37kfyvwin.fsf@trained-monkey.org>
@ 2002-11-02 10:12     ` H. J. Lu
  0 siblings, 0 replies; 3+ messages in thread
From: H. J. Lu @ 2002-11-02 10:12 UTC (permalink / raw)
  To: Jes Sorensen; +Cc: libc-hacker

On Thu, Oct 31, 2002 at 09:44:48PM -0500, Jes Sorensen wrote:
> >>>>> "HJ" == H J Lu <hjl@lucon.org> writes:
> 
> HJ> On Thu, Oct 31, 2002 at 02:50:28PM -0500, Jes Sorensen wrote:
> >> Hi
> >> 
> >> We are chasing a problem on Linux/mips with glibc-2.2.x, which I am
> >> not sure whether is a kernel bug or a libc bug. We haven't been
> >> able to reproduce it under Linux/x86 or Linux/ia64 so far though.
> >> 
> >> Basically what seems to be happening is the following, a task is
> >> spawned from fork(), the child sends some signals to the parent
> >> after which it exits.
> 
> [snip]
> 
> HJ> A testcase?
> 
> Included - but please no swearing, it's not pretty (no I didn't write
> it ;-)
> 

I couldn't tell the difference between RedHat 7.3/x86 and RedHat
7.3/mipsel. They both use glibc 2.2.5-42. x86 runs kernel 2.4.18-14
from RedHat and mipsel runs 2.4.20-pre6 from CVS.



H.J.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-11-02 18:12 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-10-31 11:57 2.2.x mips signal crash Jes Sorensen
2002-10-31 18:44 ` H. J. Lu
     [not found]   ` <m37kfyvwin.fsf@trained-monkey.org>
2002-11-02 10:12     ` H. J. Lu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).