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 pconnell
Recipients Johan Dahlin, db3l, emilyemorehouse, eric.snow, koobs, nascheme, ncoghlan, pconnell, pmpp, serhiy.storchaka, shprotx, steve.dower, vstinner, yselivanov
Date 2019-11-21.13:55:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1574344558.04.0.161892905653.issue33608@roundup.psfhosted.org>
In-reply-to
Content
Just to summarise, I'm fairly sure this is exactly what Victor saw: a daemon thread attempts to reacquire the GIL via Py_END_ALLOW_THREADS after interpreter finalisation. Obviously the threadstate pointer held by the thread is then invalid...so we crash.

So I see basically two options:

1. Don't (always) free threadstate structures in Py_Finalize, and figure out a way to avoid leaking them (if Python is re-initialized in the same process).

2. Ban this behaviour entirely, e.g. have Py_Finalize fail if there are live threads with threadstate objects.

The discussion so far assumes that we should support this, i.e. #1. Any thoughts on that? (I'll have a think about whether this is actually doable!)
History
Date User Action Args
2019-11-21 13:55:58pconnellsetrecipients: + pconnell, nascheme, db3l, ncoghlan, vstinner, pmpp, eric.snow, serhiy.storchaka, yselivanov, koobs, steve.dower, emilyemorehouse, Johan Dahlin, shprotx
2019-11-21 13:55:58pconnellsetmessageid: <1574344558.04.0.161892905653.issue33608@roundup.psfhosted.org>
2019-11-21 13:55:58pconnelllinkissue33608 messages
2019-11-21 13:55:57pconnellcreate