Daniel Franke <dfra...@wellohorld.com> added the comment:
Just FYI, I've lately been trying to track down a different threading-related
bug, and I think the fix for this one also fixed that one by accident.
Leave the following program running for a while under python-2.7.2:
---snip---
import subprocess
import threading
import random
class Forkfuzz(threading.Thread):
def run(self):
while random.randint(0,100) > threading.active_count():
Forkfuzz().start()
p = subprocess.Popen(['/bin/sleep', '1'])
p.communicate()
if __name__ == "__main__":
while True:
Forkfuzz().run()
---snip---
Eventually, you'll see a bunch of python process that are deadlocked in the
following state:
#0 sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:86
#1 0x00000000004e02ad in PyThread_acquire_lock (lock=<value optimized out>,
waitflag=<value optimized out>) at Python/thread_pthread.h:321
#2 0x00000000004e0447 in find_key (key=1, value=0x0) at Python/thread.c:268
#3 0x00000000004e053b in PyThread_get_key_value (key=38356064) at
Python/thread.c:360
#4 0x00000000004cb2f8 in PyGILState_GetThisThreadState () at
Python/pystate.c:598
#5 _PyGILState_Reinit () at Python/pystate.c:547
#6 0x00000000004e43f9 in PyOS_AfterFork () at ./Modules/signalmodule.c:979
...
The problem happens when one thread forks while another thread holds a lock on
the TLS mutex. The child process then tries to acquire this mutex, and can
never do so because the thread that holds it only exists in the parent.
When the same program is run under python-2.7.3, the problem goes away.
----------
nosy: +dfranke
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue13156>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
