Remy Noel added the comment:
closing the ticket for now.
--
resolution: -> later
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Remy Noel added the comment:
@eric.snow Unless you confirm there is no way to figure out which thread is/was
holding the GIL from a debugging session on the running process, I'll get rid
of it at the end of the week.
Should i close the ticket then or will you do it ?
Thanks
Remy Noel 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
Remy Noel added the comment:
Oh, also, i do not use any C extension (apart from the one i mentionned), so i
do not acquire/release the GIL directly (a component of the standard library
would do so).
The demon threads, mainly spend their time listening to sockets and running
short
Remy Noel added the comment:
Thank you a lot for this detailed answer.
Does the "causes of exit" may terminate the thread without releasing the GIL ?
Because as far as i can tell, none of the threads seems to own the GIL (i only
checked _PyThreadState_Current though there might b
Remy Noel added the comment:
std modules: atexit, json, os, signal, socket, ssl, subprocess, sys, time,
threading, xmlrpc.client
The non-standard extension: psutil, PIL (only for image encoding though).
The amount of threads may vary, but i may have around 20 threads at all time.
Most
Remy Noel added the comment:
The bug happens about once every two weeks on a script that is fired more than
10K times a day.
Sadly, i can't update the whole production environment to try it on the latest.
(and i was unable to trigger the bug by myself).
I was hoping we could find
New submission from Remy Noel :
I have a script (sadly, I can't publish it) spawning multiple threads that, in
rare occurences, does not manage to exit properly and get stuck forever.
More precisely, this seems to happen during Interpreter exit: The atexit
callbacks are called sucessfully
