-
Notifications
You must be signed in to change notification settings - Fork 59
Fix crash at exit by allocating QObjects on the heap #303
base: master
Are you sure you want to change the base?
Conversation
seems to work & builds just fine https://build.opensuse.org/package/show/home:ahjolinna/orion |
Thank you for contributing. I'll look into this PR/issue when I have some time. Just my two cents after glancing over it:
|
I've gone ahead and updated my PR to make both the singleton initializers for Note that also thread-safety wasn't currently an issue for
The I have also done a primitive test to verify this works in practice (i.e. all destructors are called at the right time and don't leak) by printing constructor/destructor events and checking that they all match up and are called at the right time:
|
In multiple commits between 1.6.6 and 1.6.7, some objects that derive from QObject were added which do not have their own heap allocation, but rather are global variables or live inside another object. However, because ultimately Qt owns those objects and is responsible for releasing them, they must have their own allocation. Otherwise, Qt will attempt to call free on an invalid pointer, which will most likely cause a crash on exit. This commit does not introduce a leak since the objects are released by Qt (using the QObject ownership mechanism). Note the call to `std::atexit()` can be safely removed, since the settings are also saved at `VodManager`'s destructor, which happens at application exit. Fixes: #302
This commit simplifies and uniformizes parameterless singleton initialization patterns through the code base. Additionally, and though currently not relevant, the idiom used is both thread-safe and lazy, as guaranteed by the C++11 standard. See also: https://en.cppreference.com/w/cpp/language/storage_duration#Static_local_variables Note that the initializers for the VodManager and SettingManager singletons were changed in 25575da.
In multiple commits between 1.6.6 and 1.6.7, some objects that derive
from QObject were added which do not have their own heap allocation,
but rather are global variables or live inside another object.
However, because ultimately Qt owns those objects and is responsible
for releasing them, they must have their own allocation.
Otherwise, Qt will attempt to call free on an invalid pointer, which
will most likely cause a crash on exit.
This commit should not introduce a leak since the objects are released
by Qt. Additionally, AFAICT the call to
std::atexit()
can be safelyremoved, since the settings are already saved at VodManager's
destructor, which happens at application exit.
Fixes: #302
CC @mrgreywater