Skip to content

embedded windows interpreter crashes on exit if external module loaded #1259

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

Closed
sheinb opened this issue Jan 22, 2018 · 8 comments
Closed

embedded windows interpreter crashes on exit if external module loaded #1259

sheinb opened this issue Jan 22, 2018 · 8 comments

Comments

@sheinb
Copy link

sheinb commented Jan 22, 2018

I've built a multiplatform app with an embedded scoped python interpreter using pybind11. In this app, py::exec is called (using an embedded TCL interpreter) while the interpreter is alive and I load a module built with pybind11. This seems to work, but if I execute a command from that loaded module (e.g. the add function in example.cpp) and then exit my main app, it crashes under Windows (32 and 64 bit). No errors under Mac OSX. Are there special requirements for closing down the interpreter I should be following?

Thanks,
David Sheinberg

@sheinb
Copy link
Author

sheinb commented Jan 22, 2018

Upon further testing, I realize that the crash on exit (on windows) happens for modules that are loaded into the embedded interpreter that are themselves compiled as modules using pybind11. If I import other modules from the standard python lib (or numpy, e.g.) then I don't see the error. Just loading the module also doesn't cause the crash on exit, but if a function within the module is called, the host program will consistently crash on exit.

@jagerman
Copy link
Member

Are you testing with current master? There's a fix in there (#1092) that might be related.

@sheinb
Copy link
Author

sheinb commented Jan 23, 2018

Yes, I'm using the current master. I only see the problem on Windows, though - works fine on MacOS and Linux. Maybe #1092 fixed for most, but not all, compilers?

@jagerman
Copy link
Member

No, the #1092 fix would have worked everywhere.

Can put you together a minimal example--i.e. the stripped down embedded code plus a stripped down module--where the issue still occurs, and I'll take a look.

@jagerman
Copy link
Member

(It could also expose something that isn't right in your code, as well, but will be helpful either way).

@sheinb
Copy link
Author

sheinb commented Jan 23, 2018

I can try to strip down and post (and replicate). Certainly could be an error in my code, but I'm actually only using about three pybind11 functions.

I did verify that if, instead of using the scoped_interpreter, I initialize_interpreter(), load a module and call a function in it, and exit the app without calling finalize_interpreter() then I get no error (of course it isn't a clean exit, so not ideal). If I add finalize_interpreter(), though, before leaving main, it causes the error.

@sheinb
Copy link
Author

sheinb commented Jan 23, 2018

Argh...with a bit of depends.exe exploration, I realized the problem is due to a mismatch between the runtime dlls (debug vs release). I need to make sure the pybind11 modules are compiled for Release. Not really a problem with pybind11, but might be worth pointing out the "gotcha" for would be windows users (same gotcha that always applies, of course...). Sorry for wasted bandwidth.

@sheinb
Copy link
Author

sheinb commented Jan 23, 2018

Perhaps to close the thread, I'll confirm that everything seems good with pybind11 (thank you!). In the end, the key was building my cmake nmake makefiles properly, to match my main app into which the modules I was building would be loaded:

cmake .. -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants