Author pitrou
Recipients amaury.forgeotdarc, pitrou
Date 2010-09-19.23:57:38
SpamBayes Score 1.68449e-12
Marked as misclassified No
Message-id <>
test_finalize_with_trace (in test_threading) sometimes fails because of failing to destroy the GIL (in _PyEval_FiniThreads()). This can be reproduced quite reliably by launching several copies in parallel:

$ ./python -m test.regrtest -j10 -F test_threading
test test_threading failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/", line 334, in test_finalize_with_trace
    "Unexpected error: " + ascii(stderr))
AssertionError: Unexpected error: b'Fatal Python error: pthread_mutex_destroy(gil_mutex) failed\n'

What happens is that pthread_mutex_destroy() fails with EBUSY. According to the POSIX man page:

    The implementation has detected an attempt to destroy the object referenced by mutex while it is locked or referenced (for example, while being used in a pthread_cond_timedwait() or pthread_cond_wait()) by another thread.”

After a bit of tracing, it becomes clear that Py_Finalize() calls _PyEval_FiniThreads() while another thread is taking the GIL (take_gil()). Unfortunately, this is not a situation we can avoid, since we rely on process exit to kill lingering threads: arbitrary CPython code may still be running in parallel while we are finalizing interpreter structures.

Therefore, it is likely that _PyEval_FiniThreads() should avoid destroying the mutex at all. Indeed, if we destroy the mutex, it is possible that a lingering thread tries to retake the GIL after waking up from a system call (Py_END_ALLOW_THREADS), and fails because of another fatal error ("Fatal Python error: pthread_mutex_lock(gil_mutex) failed").
Date User Action Args
2010-09-19 23:57:42pitrousetrecipients: + pitrou, amaury.forgeotdarc
2010-09-19 23:57:42pitrousetmessageid: <>
2010-09-19 23:57:40pitroulinkissue9901 messages
2010-09-19 23:57:38pitroucreate