This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]