View Revisions: Issue #5469

Summary 0005469: Crash in master on startup
Revision 28.12.2020 04:43 by jonri
Description The latest master crashes on startup every time. I've tracked it down to the PythonModule constructor, specifically when initializing the `py::dict _globals` member.

Until the recent refactor [1], this used to be a `std::unique_ptr<py::dict>` which was lazy-initialized in `getGlobals()`. I suspect that with it now being a member, pybind11 doesn't like trying to initialize a py::dict that early, and some other python initialization is supposed to take place first.

I reverted _globals to use a unique pointer that is lazy-initialized in getGlobals(), and I was then able to start up DarkRadiant. Once it started up I tested a python script and it also worked.

I commented out the cleanup code using _globals since I wasn't sure off the top of my head how it would interact with the pointer, and that caused a crash on exit. So, if reverting to a pointer is the fix for this, that will have to be dealt with properly too.

As a side note, `py::module _module` is another member of PythonModule which also used to be a pointer. It doesn't seem to be causing a problem for me but I'm not sure if it is correct either.


I'll defer to your expertise on fixing this, I'd think going back to a pointer would be fine but we'd want to logically ensure it doesn't get initialized before it's supposed to.


[1] : https://github.com/codereader/DarkRadiant/commit/4a643a91fcbbd4bdb7c451e31b96d42130f515a7#diff-833f183745cc2c5e7d8bba4fde1897e7461887deee90f9a5f0a47ef05b859c37R18
Revision 28.12.2020 04:42 by jonri
Description The latest master crashes on startup every time. I've tracked it down to the PythonModule constructor, specifically when initializing the `py::dict _globals` member.

Until the recent refactor [1], this used to be a `std::unique_ptr<py::dict>` which was lazy-initialized in `getGlobals()`. I suspect that with it now being a member, pybind11 doesn't like trying to initialize a py::dict that early, and some other python initialization is supposed to take place first.

I reverted _globals to use a unique pointer that is lazy-initialized in getGlobals(), and I was then able to start up DarkRadiant. Once it started up I tested a python script and it also worked.

I commented out the cleanup code using _globals since I wasn't sure off the top of my head how it would interact with the pointer, and that caused a crash on exit. So, if reverting to a pointer is the fix for this, that will have to be dealt with properly too.

As a side note, `py::module _module` is another member of PythonModule which also used to be a pointer. It doesn't seem to be causing a problem for me but I'm not sure if it is correct either.


I'll defer to your expertise on fixing this, I'd think going back to a pointer would be fine but we'd want to logically ensure it doesn't get initialized before it's supposed to.


[1] : https://github.com/codereader/DarkRadiant/commit/4a643a91fcbbd4bdb7c451e31b96d42130f515a7