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 jbms
Recipients gregory.p.smith, izbyshev, jbms, vstinner
Date 2021-09-15.19:03:21
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1631732601.93.0.543734509538.issue42969@roundup.psfhosted.org>
In-reply-to
Content
Another possible resolution would to simply make threads that attempt to acquire the GIL after Python starts to finalize hang (i.e. sleep until the process exits).  Since the GIL can never be acquired again, this is in some sense the simplest way to fulfill the contract.  This also ensures that any data stored on the thread call stack and referenced from another thread remains valid.  As long as nothing on the main thread blocks waiting for one of these hung threads, there won't be deadlock.


I have a case right now where a background thread (created from C++, which is similar to a daemon Python thread) acquires the GIL, and calls "call_soon_threadsafe" on an asycnio event loop.  I think that causes some Python code internally to release the GIL at some point, after triggering some code to run on the main thread which happens to cause the program to exit.  While `Py_FinalizeEx` is running, the call to "call_soon_threadsafe" completes on the background thread, attempts to re-acquire the GIL, which triggers a call to pthread_exit.  That unwinds the C++ stack, which results in a call to Py_DECREF without the GIL held, leading to a crash.
History
Date User Action Args
2021-09-15 19:03:21jbmssetrecipients: + jbms, gregory.p.smith, vstinner, izbyshev
2021-09-15 19:03:21jbmssetmessageid: <1631732601.93.0.543734509538.issue42969@roundup.psfhosted.org>
2021-09-15 19:03:21jbmslinkissue42969 messages
2021-09-15 19:03:21jbmscreate