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.

Title: subprocess.Popen inside thread locks the thread in some case (2.4)
Type: behavior Stage:
Components: Library (Lib) Versions: Python 2.4
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: astrand Nosy List: astrand, bigorilla, darkk, gregory.p.smith, ragnark, titty, tovrstra
Priority: normal Keywords: easy, patch

Created on 2006-01-13 16:05 by tovrstra, last changed 2022-04-11 14:56 by admin. This issue is now closed.

File name Uploaded Description Edit tovrstra, 2006-01-13 16:05 tovrstra, 2006-01-13 16:07
Messages (8)
msg27293 - (view) Author: Toon Verstraelen (tovrstra) Date: 2006-01-13 16:05
The bug can be verified with the example program
attached to this bugs. Two files are attached: and

When is executed the thread hangs on
subprocess.Popen, while, which is imported
by runs without problems. In fact both should
do exactly the same since doesn nothing but
importing my_thread.

My python version:

Python 2.4.2 (#1, Oct 17 2005, 09:05:20)
[GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on

If any more info is required, 
msg27294 - (view) Author: Ralf Schmitt (titty) Date: 2006-01-13 16:30
Logged In: YES 

I cannot reproduce this error on ubuntu linux using python
However, I am able to reproduce it using python 2.4.2
running on FreeBSD 4.11.

Stopping the program with ctrl-c results in the following

ralf@stronzo:~/tmp$ python 
before Popen
^CException in thread Thread-1:
Traceback (most recent call last):
  File "/usr/local/lib/python2.4/", line 442, in
  File "/home/ralf/tmp/", line 7, in run
    sp = Popen(["ls", "-al"], stdout=PIPE, stderr=STDOUT)
  File "/usr/local/lib/python2.4/", line 542,
in __init__
    errread, errwrite)
  File "/usr/local/lib/python2.4/", line 970,
in _execute_child
    data =, 1048576) # Exceptions
limited to 1 MB
OSError: [Errno 4] Interrupted system call

Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/usr/local/lib/python2.4/", line 24, in
    func(*targs, **kargs)
  File "/usr/local/lib/python2.4/", line 632, in
  File "/usr/local/lib/python2.4/", line 539, in
  File "/usr/local/lib/python2.4/", line 203, in
Error in sys.exitfunc:
Traceback (most recent call last):
  File "/usr/local/lib/python2.4/", line 24, in
    func(*targs, **kargs)
  File "/usr/local/lib/python2.4/", line 632, in
  File "/usr/local/lib/python2.4/", line 539, in
  File "/usr/local/lib/python2.4/", line 203, in
msg27295 - (view) Author: Toon Verstraelen (tovrstra) Date: 2006-01-13 16:58
Logged In: YES 

What version of glibc do you have on your ubuntu system? I
have glibc-2.3.5-r2, where r2 stands for second patch
revision from the gentoo distribution. In my case I can not
interrupt 'python'. I have to use ctrl-z and then
'kill %1'.
msg27296 - (view) Author: Ralf Schmitt (titty) Date: 2006-01-13 17:41
Logged In: YES 

glibc version 2.3.5.
If I add a time.sleep(1) at the end of I can
also reproduce this error reliably on ubuntu.
msg27297 - (view) Author: Yair Chuchem (bigorilla) Date: 2006-05-09 12:30
Logged In: YES 

this thread explains why this happens and how to solve it:
I implemented the fix locally at mine:
at, _execvpe, first line:
remove the "from errno import ...",
add a global "import errno" at the start
and change stuff imported from errno from "X" to "errno.X"
msg27298 - (view) Author: Ragnar Kjørstad (ragnark) Date: 2006-05-19 10:37
Logged In: YES 

I too have verified that the testprograms (with an
additional sleep) cause a deadlock, and that moving the
import statement out of os._execvp solves the problem.

However, there is a more generic problem. If fork() is
executed while any locks are held by other threads than the
one executing fork, it will deadlock the new process.

E.g, if you have a process with 2 threads. The first one is
doing work that requires locking. This could be imports, but
also anything else that uses other locks.

The second thread does a fork. If this is accidently done
while thread 1 held the lock, it will deadlock if the new
process needs the same lock.

Now, the most common use of fork is of course to do exec
right afterwards, in which case it doesn't really matter,
but it's not the only use of fork. 

See the rationalie in the manpage of pthread_atfork for

msg62482 - (view) Author: Leonid Evdokimov (darkk) Date: 2008-02-17 06:14
I confirm the bug.

Deadlock at Linux 2.6 (^C does not work):
Python 2.4.4 (#1, Jan  8 2008, 23:42:40) 
[GCC 4.1.1 (Gentoo 4.1.1-r3)] on linux2

Sometimes work and sometimes fails with fatal error at FreeBSD 6.3:
Python 2.4.4 (#2, Oct 31 2007, 05:20:42) 
[GCC 3.4.6 [FreeBSD] 20060305] on freebsd6

before Popen
before first line
FFatal error '_pq_insert_tail: Already in priority queue' at line 200 in
file /usr/src/lib/libpthread/thread/thr_priority_queue.c (errno = 0)
after last line          

And sometimes it deadlocks and ^C shows same traceback Ralf Schmitt
already posted.
msg62514 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2008-02-18 02:51
This appears to have been fixed in 2.5 and trunk.  2.4.x is old and in
security fixes only mode so I wouldn't expect to see this in any
official 2.4.x source tree released in the future unless the bdfl
changes his mind on that.  here's the patch to fix it (as described in
the email thread mentioned earlier):

Index: Lib/
--- Lib/   (revision 60877)
+++ Lib/   (working copy)
@@ -351,8 +351,8 @@
+import errno
 def _execvpe(file, args, env=None):
-    from errno import ENOENT, ENOTDIR
     if env is not None:
         func = execve
@@ -379,7 +379,7 @@
             func(fullname, *argrest)
         except error, e:
             tb = sys.exc_info()[2]
-            if (e.errno != ENOENT and e.errno != ENOTDIR
+            if (e.errno != errno.ENOENT and e.errno != errno.ENOTDIR
                 and saved_exc is None):
                 saved_exc = e
                 saved_tb = tb
Date User Action Args
2022-04-11 14:56:15adminsetgithub: 42795
2008-02-18 02:51:39gregory.p.smithsetstatus: open -> closed
type: behavior
components: + Library (Lib), - Interpreter Core
title: subprocess.Popen inside thread locks the thread in some case -> subprocess.Popen inside thread locks the thread in some case (2.4)
keywords: + patch, easy
nosy: gregory.p.smith, titty, astrand, tovrstra, bigorilla, ragnark, darkk
messages: + msg62514
resolution: wont fix
2008-02-17 06:14:49darkksetnosy: + darkk
messages: + msg62482
2008-01-17 01:48:44gregory.p.smithsetnosy: + gregory.p.smith
2006-01-13 16:05:31tovrstracreate