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.

Author neologix
Recipients neologix, pitrou, vstinner
Date 2011-06-11.09:59:03
SpamBayes Score 2.5549898e-09
Marked as misclassified No
Message-id <>
I think it might be related to Issue #6721.

Using a mutex/condition variable after fork (from the child process) is unsafe: it can lead to deadlocks, and on OS-X, it seems like it can lead to segfaults.

Normally, Queue's synchronization primitives are reinitialized after fork, see Queue._after_fork() method.

But here, what happens is the following (well, that's an hypothesis):

Lib/multiprocessing/", line 270 in _bootstrap
        _current_process = self

- the old _current_process' reference count drops to zero
- it's deallocated, and since it holds the last reference to a Queue, the queue is finalized
- as a consequence, the Queue._finalize_close() callback (registered through a Finalize object) is called
- Queue._finalize_close() tries to acquire, signal and release the _notempty Condition, but the Condition hasn't been reinitialized yet, because util._run_after_forkers() is called 2 lines below
- segfault

It's probably been triggered by Antoine's patches, but I'm pretty sure this bug has always been there.

I think that moving util._run_after_forkers() up 2 lines should fix the segfaults, but with that change test_number_of_objects fails (I didn't investigate why).
Date User Action Args
2011-06-11 09:59:04neologixsetrecipients: + neologix, pitrou, vstinner
2011-06-11 09:59:04neologixsetmessageid: <>
2011-06-11 09:59:03neologixlinkissue12310 messages
2011-06-11 09:59:03neologixcreate