This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/4737] fork is not async-signal-safe
- From: "nmiell at comcast dot net" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 21 Oct 2008 05:12:26 -0000
- Subject: [Bug libc/4737] fork is not async-signal-safe
- References: <20070704013541.4737.nmiell@comcast.net>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From nmiell at comcast dot net 2008-10-21 05:12 -------
(In reply to comment #2)
> I am no glibc hacker, and I am not sure how to fix this bug. If the locking is
> needed, perhaps signals should be blocked while the lock is held?
Unfortunately, that's only a partial solution -- applications generally expect
to get their signals, even if they're in the bowels of the memory allocator.
The original thing that inspired this bug entry was a SIGSEGV in malloc()
leading to an attempt to fork and exec GNOME's bug-buddy leading to a deadlock.
Masking signals would prevent this valid usage scenario and annoy users.
And this is completely ignoring the performance impact of two system calls for
every malloc operation.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=4737
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.