You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm getting the following exception consistently from hanging_threads:
Exception in thread Thread-6:
Traceback (most recent call last):
File "/usr/lib/python3.6/threading.py", line 916, in _bootstrap_inner
self.run()
File "/usr/lib/python3.6/threading.py", line 864, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/lib/python3.6/dist-packages/hanging_threads.py", line 97, in monitor
new_threads = get_current_frames()
File "/usr/local/lib/python3.6/dist-packages/hanging_threads.py", line 148, in get_current_frames
for thread_id, frame in sys._current_frames().items()
File "/usr/local/lib/python3.6/dist-packages/hanging_threads.py", line 148, in <genexpr>
for thread_id, frame in sys._current_frames().items()
KeyError: 140058396972800
When I look at that code and run the following two commands I get some odd results:
[thread_id for thread_id, frame in sys._current_frames().items()]
[t.ident for t in threading.enumerate()]
The first one is derived from the hanging_threads code using sys._current_frames(), in that output the thread_id for one or two of the entries is changing every time I run that command while in a debugging session. This appears to be the core of the problem, the thread_id is invalid while building the dictionary. In the second case, using threading.enumerate() the thread IDs remain constant.
I've tested this in Python 3.6 and 3.7.4.
I noted the following issues which reference a bug in sys._current_frames() but seems to suggest it was fixed perhaps in 3.4/3.5 (I'm not really familiar with the bug).
I would think, go for experimentation with threading.enumerate().
It might be that the thread is deleted very fast. threading.enumerate() should be the save option.
This is not a bug in Python. It is a race condition trying to compare threads between the output sys._current_frames() vs threading.enumerate(). If a thread exits in between the two calls, you get the crash. I submitted issue #89 with a rewrite of get_current_frames() that fixes the crash. Sorry I don't have the time to create a PR right now.
I'm getting the following exception consistently from hanging_threads:
When I look at that code and run the following two commands I get some odd results:
The first one is derived from the hanging_threads code using
sys._current_frames()
, in that output thethread_id
for one or two of the entries is changing every time I run that command while in a debugging session. This appears to be the core of the problem, thethread_id
is invalid while building the dictionary. In the second case, usingthreading.enumerate()
the thread IDs remain constant.I've tested this in Python 3.6 and 3.7.4.
I noted the following issues which reference a bug in
sys._current_frames()
but seems to suggest it was fixed perhaps in 3.4/3.5 (I'm not really familiar with the bug).At this point I'm a little uncertain how to proceed, my options seem to be:
threading.enumerate()
.sys._current_frames()
better.I'd love some thoughts from someone with more experience here.
The text was updated successfully, but these errors were encountered: