Message339141
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. |
|
Date |
User |
Action |
Args |
2019-03-29 19:56:28 | eric.snow | set | recipients:
+ eric.snow, methane, mocramis |
2019-03-29 19:56:27 | eric.snow | set | messageid: <1553889387.99.0.215153808042.issue36469@roundup.psfhosted.org> |
2019-03-29 19:56:27 | eric.snow | link | issue36469 messages |
2019-03-29 19:56:27 | eric.snow | create | |
|