This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: questions about bug 4737 (fork is not async-signal-safe)
- From: Norbert van Bolhuis <nvbolhuis at aimvalley dot nl>
- To: Jonathan Nieder <jrnieder at gmail dot com>
- Cc: libc-help at sourceware dot org
- Date: Wed, 11 May 2011 12:58:27 +0200
- Subject: Re: questions about bug 4737 (fork is not async-signal-safe)
- References: <4DC94C42.4040907@aimvalley.nl> <20110511030438.GA2925@elie>
Hi Jonathan,
Thanks for your response.
The reason is I'm running into the corrupted _IO_list_all
problem for some of our application threads that use system(3)
(which is implemented with fork + exec).
POSIX.1-2008 does not list system as an async-signal-safe function.
But that should not be relevant here:
I believe it is caused by our application that can stop
the threads asynchronously by using pthread_cancel.
Note that libc implements pthread_cancel by sending a
SIGCANCEL (signr=32) with tkill.
One only needs to worry about whether a function is async-signal-safe
if planning to use it from within a signal handler.
Ok. Well it's just that the corrupted _IO_list_all problem is reported
in bug 4737.
Bug 4737 mentions 2 separate problems. The one I'm talking about
indeed might be unrelated to fork not being async-signal-safe. This is
one of the reasons I referred to others sufferring from the corrupted
_IO_list_all problem.
On the other hand, bug 4737 mentions a discussion held on libc-hacker,
see:
http://www.sourceware.org/ml/libc-hacker/2007-02/msg00009.html
It has an example program that shows the issue. It's using calloc and
another thread doing fork which is interrupted by a signal, but there is
no use of fork from within a signal handler!
So let's look for other explanations. Are you saying your threads use
the asynchronous cancellability type? If I am reading the standard
correctly then the only functions guaranteed safe to use in such a
thread are pthread_cancel(), pthread_setcancelstate(), and
pthread_setcanceltype().
No, we do not use the asynchronous cancellability type (PTHREAD_CANCEL_ASYNCHRONOUS).
Our threads use the default canceltype (PTHREAD_CANCEL_DEFERRED).
They never use pthread_testcancel, so they rely on the (libc) functions
that are a cancellation point (whoever that maybe).
well at least my signal(7) man page says fork is async-signal-safe)
That's true. Current POSIX requires fork to be async-signal-safe. It
will probably change with issue 8 of the standard; see
http://austingroupbugs.net/view.php?id=62 for some details.
Is this bug solved in the latest glibc ?
I don't know. I'd suggest trying and seeing. :)
Yeah.
The problem is that it is a lot of work to move to a new glibc.
I'm just trying to fully understand the problem and then judge whether
our app really needs this bug fixed.
Thanks and Regards,
Norbert.