public inbox for libc-hacker@sourceware.org
 help / color / mirror / Atom feed
From: Jes Sorensen <jes@trained-monkey.org>
To: libc-hacker@sources.redhat.com
Subject: 2.2.x mips signal crash
Date: Thu, 31 Oct 2002 11:57:00 -0000	[thread overview]
Message-ID: <200210311950.g9VJoST18983@trained-monkey.org> (raw)

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

             reply	other threads:[~2002-10-31 19:50 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-31 11:57 Jes Sorensen [this message]
2002-10-31 18:44 ` H. J. Lu
     [not found]   ` <m37kfyvwin.fsf@trained-monkey.org>
2002-11-02 10:12     ` H. J. Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200210311950.g9VJoST18983@trained-monkey.org \
    --to=jes@trained-monkey.org \
    --cc=libc-hacker@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).