-
Notifications
You must be signed in to change notification settings - Fork 27.5k
pybind11::gil_scoped_release: crash on exit with daemon threads #38228
Copy link
Copy link
Open
Labels
high prioritymodule: crashProblem manifests as a hard crash, as opposed to a RuntimeErrorProblem manifests as a hard crash, as opposed to a RuntimeErrormodule: dependency bugProblem is not caused by us, but caused by an upstream library we useProblem is not caused by us, but caused by an upstream library we usetriagedThis issue has been looked at a team member, and triaged and prioritized into an appropriate moduleThis issue has been looked at a team member, and triaged and prioritized into an appropriate module
Metadata
Metadata
Assignees
Labels
high prioritymodule: crashProblem manifests as a hard crash, as opposed to a RuntimeErrorProblem manifests as a hard crash, as opposed to a RuntimeErrormodule: dependency bugProblem is not caused by us, but caused by an upstream library we useProblem is not caused by us, but caused by an upstream library we usetriagedThis issue has been looked at a team member, and triaged and prioritized into an appropriate moduleThis issue has been looked at a team member, and triaged and prioritized into an appropriate module
🐛 Bug
Our use of
pybind11::gil_scoped_releasecan cause crashes when used with daemon threads (from thethreadingpackage) and with C++ created threads that acquire/release the GIL. Note that we previously used AutoNoGIL, but that has the same problem.This manifests as a crash on exit with a message like:
The problem occurs when a thread tries to acquire the GIL during Python interpreter finalization. The interpreter calls
pthread_exit(0)to terminate the thread. Note that the call is from the destructor ofgil_scoped_release. The glibcpthread_exitimplementation uses unwind; calling unwind from a destructor has similar problems to throwing C++ exceptions from destructors. This triggers the call tostd::terminateand the abort.Here is some code that reproduces the issue. I think #22924 is essentially the same issue. I've also seen this happen in research code that mixes C++ threads with Python.
cc @ezyang @gchanan @zou3519