Remy Noel <remy.n...@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 <rep...@bugs.python.org>
<https://bugs.python.org/issue36469>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
