Eliminate complex typed static variables#37
Eliminate complex typed static variables#37espakm wants to merge 1 commit intocommontk:patched-5from
Conversation
Complex typed static variables (e.g. maps) in dll-s are to avoid. On Windows they are not initialised in time (or at all) when the dll is dynamically loaded. The current use of static QHash data members results in crash on Windows when the PythonQt.dll is loaded. See details here: http://stackoverflow.com/questions/5114683/loading-dll-not-initializing-static-c-classes
|
Thanks for the updated PR. I will test and integrate later this afternoon (EST time) |
|
As suggested by Florian, may be a first patch would be to |
|
@espakm Based on the description I pushed a branch where I added a test attempting to reproduce the problem: See patched-5...jcfr:37-python-init-crash But it passes on both Linux and Windows (using either VS2008 or VS2013 for a Release build of PythonQt built against a release build of Qt and Python) |
|
Moving execution of PythonQt tests into the static initializer causes the test to fail. Failure is the following: |
|
Commit c891272 causes test to also fail on Linux |
|
"Moving execution of PythonQt tests into the static initializer causes the test to fail." Yes, that's exactly the point. The crash happens when PythonQt is initialised from the static initialiser of a library. (And PythonQt has not been loaded beforehand.) |
Complex typed static variables (e.g. maps) in dll-s are to avoid.
On Windows they are initialised late when the dll
is being loaded dynamically. The current use of static QHash data members
results in crash on Windows when a PythonQt.dll static function is called from a static initialization code from a dependent library, and PythonQt.dll has not been loaded before, already.
See details here:
http://stackoverflow.com/questions/5114683/loading-dll-not-initializing-static-c-classes