Repository navigation
Building python modules with static runtime #1618
Description
Am I correct that if I use pybind11 to build python modules (pyd shared libraries on windows) with static runtime things can go horribly bad?
Details
It is not as obvious from docs, but while looking at the code I've figured out that: there is this shared internals object (see get_internals()). Which contains a lot of std containers. If my application would have say 2 pybind11 modules it could happen that allocation/deallocation will happen across dll boundaries? Moreover static runtimes can be different. Not to mention potential ABI incompatibility.
Follow up question
If I make every pybind11 module with own internals (by having unique PYBIND11_INTERNALS_ID) what would the downsides be? What features will be lost?
Activity
pavolmarkovic-serato commentedon Oct 8, 2020
I've hit related problem when loading 2 modules built with diffent runtimes (one dynamic and one static) with vc140.
Exceptions thrown in C++ code are translated to Python exceptions through registered translators. The last loaded translator has same internals ID (since both modules are using same pybind version and release configuration) so it would pass generic exceptions to first registered module. In the process of rethrowing the exception in the other module the python process crashed with 0xC000005 error code.
I could not reproduce the issue when both modules were built with vc142 compiler.
pwuertz commentedon Jul 26, 2023
Just found this issue, realizing that you guys already figured out what is happening in NVIDIA/TensorRT#2853 and #2898 almost 5 years ago :(