[issue36469] Stuck during interpreter exit, attempting to take the GIL
Remy Noel
report at bugs.python.org
Sat Mar 30 06:16:05 EDT 2019
Remy Noel <remy.noel at blade-group.com> added the comment:
Thanks for the advicesand thorough analysis. I'll try to force threads shutdown from the cleanup callback but i'd like to dig to the root of this isssue if possible.
This is what the thread 7 python backtrace looks like:
(gdb) py-bt
Traceback (most recent call first):
<built-in method acquire of _thread.lock object at remote 0x7f43088859b8>
File "/usr/lib/python3.5/threading.py", line 293, in wait
waiter.acquire()
File "/usr/lib/python3.5/threading.py", line 549, in wait
signaled = self._cond.wait(timeout)
File "/usr/lib/python3.5/threading.py", line 849, in start
self._started.wait()
File "...", line 44, in __init__
thr.start()
So we are basically spawning a thread and waiting for it to start (which will likely never happen). That seems like a "normal" behaviour for me (from a programming standpoint, that is), but this may be another cause of never-terminating threads. (unless this is also caused by the headlock and the thread is expected to spawn/release the lock even after finalizing.)
Also, i have access to the process that i kept running. Is there any way to me to figure out which thread is currently holding the GIL ? I just want to be sure i can't get this info myself before we close this ticket (at which point i will get rid of the culprit process).
----------
_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36469>
_______________________________________
More information about the Python-bugs-list
mailing list