Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exception: KeyError: 140058396972800 #88

Open
davidparks21 opened this issue Oct 3, 2019 · 2 comments
Open

Exception: KeyError: 140058396972800 #88

davidparks21 opened this issue Oct 3, 2019 · 2 comments

Comments

@davidparks21
Copy link

davidparks21 commented Oct 3, 2019

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).

At this point I'm a little uncertain how to proceed, my options seem to be:

  • Experiment with using threading.enumerate().
  • Try to understand the underlying issue with sys._current_frames() better.

I'd love some thoughts from someone with more experience here.

@niccokunzmann
Copy link
Owner

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.

@remdragon
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants