You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee=Noneclosed_at=<Date2007-10-05.18:32:05.611>created_at=<Date2007-10-04.21:31:57.630>labels= ['library', 'type-crash']
title='subprocess is not thread-safe'updated_at=<Date2010-11-08.16:26:07.710>user='https://bugs.python.org/kjddudaorg'
It crashes because when one thread calls subprocess.Popen(), subprocess
calls this _cleanup() function, which might reap the subprocess started
in another thread ! The other thread might be inside
subprocess.Popen.wait(), just about to call waitpid(), and kill itself.
If you uncomment the commented line, then the program runs with no problems.
I imagine the purpose of _cleanup is to protect users from themselves,
i.e., protect a user who calls subprocess.Popen() a lot without ever
calling wait(). I suggest either:
(1) eliminating this _cleanup() mechanism completely; people who do
not wait() deserve the zombies they get;
(2) synchronizing _cleanup() with wait() through a lock; or,
(3) having wait() simply retry if it gets ECHILD. On the retry, it
will discover that returncode is set, and return normally.
"""
Last time I looked this had been fixed, admittedly in a bit of an ugly
way, on the svn head. I offered to do a patch to make it a bit cleaner,
but as it isn't really broken anymore it was a bit of a low priority and
I haven't done it.
This bug seems to have a good repeatable test-case that we can probably
use in the unittests to show that it's now fixed...
"""
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: