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/process.py", line 270 in _bootstrap
:
_current_process = self
util._finalizer_registry.clear()
util._run_after_forkers()
- 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).