Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 85483 - fork() and system() need to be thread safe
Summary: fork() and system() need to be thread safe
Alias: None
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: glibc
Version: 2.1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-03-03 17:58 UTC by Larry Troan
Modified: 2016-11-24 12:04 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-10-03 11:13:14 UTC
Target Upstream Version:

Attachments (Terms of Use)
sample code to generate error (deleted)
2003-03-03 18:02 UTC, Larry Troan
no flags Details

Description Larry Troan 2003-03-03 17:58:26 UTC
When the attached test case is compiled as "gcc -pthreads ptest.c" on an IPF Red
Hat system, the executable will occasionally hang when run.

The problem is that the code is calling system() from within a parallel region.
 System() does a fork(), cloning the address space.  If the data structures for
the various locks are cloned at the moment when they are locked by one of the
other threads, then they will appear to be locked to the new fork()ed process. 
If the forked process then needs to acquire one of these locked locks, then it
will wait for the lock to be released, but of course, it will never be released,
thereby hanging that process.

If the glibc implementation of fork() cleaned up(reinitialized) these data
structures via the pthread_atfork() call, fork would be thread safe.  Presumably
pthreads already cleans up its internal state at a fork.

Our question is whether fork() (and therefore system()) is intended to be thread
safe, or whether these calls are not intended to be thread safe.  If they are
intended to be thread safe, this is a bug.  If not, this can be considered a
feature request.  We are interested in knowing the intent in addition to the

Action by: joegoodman
Issue Registered
Action by: joegoodman
Test case attached.

Status set to: Waiting on Tech
File uploaded: ptest.c

ISSUE TRACKER 16102, opened by Intel as sev 3.

Comment 1 Larry Troan 2003-03-03 18:02:04 UTC
Created attachment 90456 [details]
sample code to generate error

Comment 2 Jakub Jelinek 2003-03-10 15:52:15 UTC
Cannot reproduce. Have tried ~ 150 runs on glibc-2.2.4-31.7 and ~ 50 runs
on glibc-2.3.2-5 without a single hang on 4way Itanium2 with 2.4.18-e.14smp

Comment 3 Larry Troan 2003-03-20 15:56:28 UTC
Couldn't reproduce this on glibc-2.3.2-5 (have run it about 50 times without any

Comment 4 Larry Troan 2003-03-20 16:01:42 UTC
THAT'S INTEL (NOT HP)..... sorry

Comment 5 Larry Troan 2003-03-31 13:37:08 UTC
Event posted 03-27-2003 05:49pm by joegoodman with duration of 0.00
 I have notified the person who brought this issue to my attention.  He is also
having difficulty reproducing the problem at this time.  We will let you know if
it is reproduced again.

Comment 6 Larry Troan 2003-04-14 13:47:31 UTC
------- Additional Comments From  2003-03-20 10:56 -------
Couldn't reproduce this on glibc-2.3.2-5 (have run it about 50 times without any

Event posted 03-31-2003 08:37am by ltroan with duration of 0.00        
Status set to: Fix Pending         

Event posted 03-31-2003 02:05pm by joegoodman with duration of 0.00        
If this issue was set to "Fix Pending" based on my response, that would not be
accurate.  We have no evidence it is fixed.  Do you have additional evidence?

Event posted 04-09-2003 08:08pm by joegoodman with duration of 0.00       
Assigned back for explanation.
Status set to: Waiting on Tech

Comment 7 Larry Troan 2003-04-14 13:52:05 UTC
Per above, RH's Jakub could not reproduce the problem on glibc-2.3.2-5 in about
50 attempts. I interpreted your remarks to mean that you could not reproduce the
problem either on more recent code and therefore marked it as "fix pending."

Joe, unless Intel can reproduce it on RHEL 2.1AS QU2 beta (which is post e.16
kernel), I think we have to assume it's fixed. Do you agree? 

Comment 8 Larry Troan 2003-10-03 11:13:14 UTC
Per request from Engineering, closing as fixed. If still a problem, we can
reopen with new data.

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