Bug 85483 - fork() and system() need to be thread safe
fork() and system() need to be thread safe
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: glibc (Show other bugs)
2.1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-03-03 12:58 EST by Larry Troan
Modified: 2016-11-24 07:04 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-10-03 07:13:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
sample code to generate error (3.63 KB, text/plain)
2003-03-03 13:02 EST, Larry Troan
no flags Details

  None (edit)
Description Larry Troan 2003-03-03 12:58:26 EST
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
resolution.

----------
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 13:02:04 EST
Created attachment 90456 [details]
sample code to generate error
Comment 2 Jakub Jelinek 2003-03-10 10:52:15 EST
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
kernel.
Comment 3 Larry Troan 2003-03-20 10:56:28 EST
FROM JAKUB....
Couldn't reproduce this on glibc-2.3.2-5 (have run it about 50 times without any
problems).
----
HP CAN YOU CONFIRM IT'S FIXED?

Comment 4 Larry Troan 2003-03-20 11:01:42 EST
THAT'S INTEL (NOT HP)..... sorry
Comment 5 Larry Troan 2003-03-31 08:37:08 EST
FROM ISSUE TRACKER
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 09:47:31 EDT
FROM ISSUE TRACKER...........
------- Additional Comments From ltroan@redhat.com  2003-03-20 10:56 -------
FROM JAKUB....
Couldn't reproduce this on glibc-2.3.2-5 (have run it about 50 times without any
problems).
----
INTEL, CAN YOU CONFIRM IT'S FIXED?

--------------------------------------------
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 09:52:05 EDT
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 07:13:14 EDT
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.