Bug 112517 - pthread_atfork() handlers not called by system()
Summary: pthread_atfork() handlers not called by system()
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: 1
Hardware: athlon
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-12-22 01:59 UTC by Jeff Epler
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2003-12-22 21:38:08 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Jeff Epler 2003-12-22 01:59:29 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.7-10 i586)

Description of problem:
A handler installed by pthread_atfork() should be executed during a
call to system(), but it is not

Version-Release number of selected component (if applicable):
glibc-2.3.2-101.1

How reproducible:
Always

Steps to Reproduce:
1.Compile attached program "gcc pthread_bug.c -lpthread"
2.Execute it "./a.out"
3.Check exit status: 1 indicates presence of bug, 0 indicates absence
of bug
    

Actual Results:  Program exits with 1 because the global variable was
never modified by the pthread_atfork handler

Expected Results:  Program exits with 0 because the global variable
was modified by the pthread_atfork handler

Additional info:

This is the program:
#include <pthread.h>
#include <stdlib.h>

int g = 0;

void f(void) { g=1; }

int main(void) {
        pthread_atfork(f, NULL, NULL);
        system("true");
        return g==1 ? EXIT_SUCCESS : EXIT_FAILURE;
}

Comment 1 Jakub Jelinek 2003-12-22 08:53:54 UTC
Why?
There is no word about system() in
http://www.opengroup.org/onlinepubs/007904975/functions/pthread_atfork.html
and there doesn't seem to be anything in
http://www.opengroup.org/onlinepubs/007904975/functions/system.html
that would mandate system() to be implemented using fork() function.

Comment 2 Jeff Epler 2003-12-22 13:01:11 UTC
I base my claim that pthread_atfork() should be called by system()
from reading
http://www.opengroup.org/onlinepubs/007904975/functions/system.html

The third paragraph under the heading "description" says this:
"[CX] The environment of the executed command shall be as if a child
process were created using fork(), and the child process invoked the
sh utility using execl() as follows [...]"

The rationale section expands on what the "environment of the executed
command" is:
"IEEE Std 1003.1-2001 places additional restrictions on system(). It
requires that if there is a command language interpreter, the
environment must be as specified by fork() and exec. This ensures, for
example, that close-on- exec works, that file locks are not inherited,
and that the process ID is different."

The pthread_atfork web page says it
"provides multi-threaded application programs with a standard
mechanism for protecting themselves from fork() calls in a library
routine or the application itself."
I believe that system() is one such library routine, since it is
specified to create an environment "as specified by fork()".

This issue arose in the context of Python.  For various reasons,
signals are blocked in all threads besides the main thread.  This
means that in processes generated by fork() from subthreads, all
signals are blocked, which leads to undesired behavior.  Using the
child argument of pthread_atfork() allows signals to be unblocked when
using fork()+exec() to execute an external program, but not when
system() is used.

Comment 3 Roland McGrath 2003-12-22 21:37:44 UTC
I think it is clear that the specification refers to the elements of
the child process state that survive exec, so that the executed
command can perceive them as part of its "environment".  You could
submit an interpretation request, but I think the committee would
concur with my reading.  The specification of pthread_atfork refers to
calls to fork, not to other parts of the POSIX.1 implementation.  If
your application calls system, and not fork, those clauses do not
apply to it.


Note You need to log in before you can comment on or make changes to this bug.