questions about bug 4737 (fork is not async-signal-safe)

[Norbert van Bolhuis]

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.