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 eric.snow
Recipients eric.snow, methane, mocramis
Date 2019-03-29.19:56:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1553889387.99.0.215153808042.issue36469@roundup.psfhosted.org>
In-reply-to
Content
Looking at the stack traces for all your threads (super helpful, BTW), I saw 4 groups:

* (1) main thread (blocked on GIL during runtime finalization)
   + Thread 1
* (12) blocked on GIL in call to PyEval_RestoreThread() (socket, select, time.sleep(), file.read())
* (3) waiting for a connection on a socket (with GIL not held, presumably)
   + Thread 5
   + Thread 12
   + Thread 14
* (1) blocked on a threading.Lock
   + Thread 7
* (1) blocked on "head" lock when cleaning up after execution
   + Thread 18

So there's a third lock involved in this deadlock.  It isn't actually clear to me (without further digging) which thread actually holds the GIL.  I'd guess it's one of the last two (though it could be one of the 3 waiting on a socket).  However, in each of those cases I would not expect the GIL to be held at that point.

Regardless, the race likely involves the threading.Lock being held late in finalization.  It could be that you are not releasing it somewhere where you should be.
History
Date User Action Args
2019-03-29 19:56:28eric.snowsetrecipients: + eric.snow, methane, mocramis
2019-03-29 19:56:27eric.snowsetmessageid: <1553889387.99.0.215153808042.issue36469@roundup.psfhosted.org>
2019-03-29 19:56:27eric.snowlinkissue36469 messages
2019-03-29 19:56:27eric.snowcreate