Py_Finalize could potentially invoke code that calls `get_internals()`, which could create a new internals object if one didn't exist. `finalize_interpreter()` didn't catch this because it only used the pre-finalize interpreter pointer status; if this happens, it results in the internals pointer not being properly destroyed with the interpreter, which leaks, and also causes a `get_internals()` under a future interpreter to return an internals object that is wrong in various ways.
| Name |
Last commit
|
Last Update |
|---|---|---|
| docs | Loading commit data... | |
| include/pybind11 | Loading commit data... | |
| pybind11 | Loading commit data... | |
| tests | Loading commit data... | |
| tools | Loading commit data... | |
| .appveyor.yml | Loading commit data... | |
| .gitignore | Loading commit data... | |
| .gitmodules | Loading commit data... | |
| .readthedocs.yml | Loading commit data... | |
| .travis.yml | Loading commit data... | |
| CMakeLists.txt | Loading commit data... | |
| CONTRIBUTING.md | Loading commit data... | |
| ISSUE_TEMPLATE.md | Loading commit data... | |
| LICENSE | Loading commit data... | |
| MANIFEST.in | Loading commit data... | |
| README.md | Loading commit data... | |
| setup.cfg | Loading commit data... | |
| setup.py | Loading commit data... |