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

Summary: fork() and system() need to be thread safe
Product: Red Hat Enterprise Linux 2.1 Reporter: Larry Troan <ltroan>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED CURRENTRELEASE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 2.1CC: fweimer, ichute, lwoodman, tao
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-10-03 11:13:14 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Description Flags
sample code to generate error none

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.