This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Race condition in popen2
Type: Stage:
Components: Library (Lib) Versions: Python 2.3
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: nnorwitz Nosy List: kenmcneil, nnorwitz, sf-robot
Priority: high Keywords:

Created on 2004-02-08 17:31 by kenmcneil, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (4)
msg19942 - (view) Author: Ken McNeil (kenmcneil) Date: 2004-02-08 17:31
The "fix" for bug #761888 created a race condition in
Popen3  . The interaction between wait and _cleanup is
the root of the problem.

def wait(self):
  """Wait for and return the exit status of the child
process."""
  if self.sts < 0:
    pid, sts = os.waitpid(self.pid, 0)
    if pid == self.pid:
      self.sts = sts
  return self.sts

def _cleanup():
    for inst in _active[:]:
        inst.poll()

In wait, between the check of self.sts and the call to
os.waitpid a new Popen3 object can be created in
another thread which will trigger a call to _cleanup.
Since the call to _cleanup polls the process, when the
thread running wait starts back up again it will try to
poll the process using os.waitpid, which will throw an
OSError because os.waitpid has already been called for
the PID indirectly in _cleanup.

A work around is for the caller of wait to catch the
OSError and check the sts field, and if sts is
non-negative then the OSError is most likely because of
this problem and can be ignored. However, sts is
undocumented and should probably stay that way.

My suggestion is that the patch that added _active, 
_cleanup, and all  be removed and a more suitable
mechanism for fixing bug #761888 be found. As it has
been said in the discussion of bug #761888, magically
closing FDs is not a "good thing". It seems to me that
surrounding the call to os.fork with a try/except, and
closing the pipes in the except, would be suitable but
I don't know how this would interact with a failed call
to fork, therefore I wont provide a patch.
msg19943 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2006-03-23 08:47
Logged In: YES 
user_id=33168

I believe this is basically a duplicate of 1183780.  There
is a patch attached there.  Can you verify if it fixes your
problem?
msg19944 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2006-03-25 04:56
Logged In: YES 
user_id=33168

Martin and I worked out a patch which should solve this
problem and it was committed.  For more info see bug
1183780,   If this does not solve the problem, change the
status from pending to open.  Otherwise, this bug report
should close automatically in a couple of weeks since it's
pending.
msg19945 - (view) Author: SourceForge Robot (sf-robot) Date: 2006-04-09 02:20
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
History
Date User Action Args
2022-04-11 14:56:02adminsetgithub: 39917
2004-02-08 17:31:21kenmcneilcreate