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
[OS] Process.open_files()
unsafe API usage can lead to deadlock
#1967
Labels
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary
Description
The design of
Process.open_files()
has a serious design flaw that can lead to a deadlock. Per the psutil documentation:Beyond this risk of missing data, this API also carries a deadlock risk.
The thread monitoring/termination logic is implemented here:
psutil/psutil/arch/windows/process_handles.c
Lines 166 to 177 in ac898c7
The danger is that if the target thread is terminated while it is holding a lock, it can deadlock the entire process. MSDN warns about this here:
In our environment, we were seeing deadlocks in python.exe where something had taken the loader lock then died. Unfortunately the thread was gone by the time we could inspect it with a debugger, leading to cryptic deadlocks, but
!locks
indicated that the loader lock was owned by a non-existent thread.There was no thread
4c4
when we were able to dump that process.Note that the loader lock is not the only lock that can cause a deadlock. In fact, many times when this deadlock occurs,
!locks
will not indicate anything abnormal.Reproduction
To reproduce this, do the following on Windows (any version, really):
Using PyExt for symbols, we can see the call stack hung in
open_files
:The text was updated successfully, but these errors were encountered: