-
Notifications
You must be signed in to change notification settings - Fork 587
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
Thread safety when usage with Pytest, and Coverage cause unexpected hang at exit #4052
Comments
When running |
Thanks @nickittynack, corroborating evidence is super useful! If you could extract a minimal reproducer, a bug that we can replay as desired is most of the way to being fixed. |
Hey @Zac-HD unfortunately I've been unable to reproduce it in a new project, or a new Django project. I understand that that's not super helpful for you! It is no longer an issue for us as we have removed the package from our projects. |
I've run into the same issue as well. In our environment, the following works as a minimal reproducer:
The above hangs if In an attempt to isolate the test from my local environment, I tried running it in a python docker container, and I found that it only seems to manifest under python 3.11.2. Maybe it's not that big a deal given the specific set of conditions, but probably still worth investigating. |
@gurudave I'm not seeing an attachment, mind including it inline? |
Appears to be introduced in 6.103.4 and existing until the current version (6.108.2) but appears to happen specifically in our network-isolated environments (like a network-jailed build container). When doing deep level logging of the python interpreter, it appears specifically to be blocked during the destruction/cleanup phase, meaning there's either a stray thread or reference not being cleaned up properly when Coverage runs with the pytest hypothesis plugin. My current theory is that the new
thread_local()
internal cache has mutable structures shared out as references to the thread-local objects themselves because of their mutability instead of handling that thread-local nature entirely within the cache logic. The sharing of that reference means it no longer necessarily abides by thread-safety if a new thread is forked because the stored reference still points at the object (though admittedlythread_local
itself has strange enough semantics that perhaps I misunderstand it as well).I'm attempting to build an actual reproduction of the issue that is easily verifiable, but it may take time to get all of it set up properly and want to get the issue known about in case any others find a similar issue.
The text was updated successfully, but these errors were encountered: