From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29223 invoked by alias); 31 Oct 2002 19:50:29 -0000 Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sources.redhat.com Received: (qmail 29146 invoked from network); 31 Oct 2002 19:50:27 -0000 Received: from unknown (HELO trained-monkey.org) (209.217.122.11) by sources.redhat.com with SMTP; 31 Oct 2002 19:50:27 -0000 Received: (from jes@localhost) by trained-monkey.org (8.11.6/8.9.3) id g9VJoST18983; Thu, 31 Oct 2002 14:50:28 -0500 Date: Thu, 31 Oct 2002 11:57:00 -0000 Message-Id: <200210311950.g9VJoST18983@trained-monkey.org> From: Jes Sorensen To: libc-hacker@sources.redhat.com Subject: 2.2.x mips signal crash X-SW-Source: 2002-10/txt/msg00114.txt.bz2 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 #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