Prevent segmentation faults caused by unfavorable ordering of static destructors

[kempniu]

Invoking the QSettings destructor from a destructor of a static variable (static QNapiConfig cfg) is a bad idea. In case the configuration file has not been changed since it was last sync()'ed, QConfFileSettingsPrivate::syncConfFile() will create a QFileInfo instance and then call its lastModified() method, which (a few calls down the chain) depends on the default constructor of QDateTime() to succeed. The problem with that constructor is that (at least until Qt 5.7 inclusive) it calls defaultDateTimePrivate(), which is defined using Q_GLOBAL_STATIC_WITH_ARGS (so it is basically another static entity whose destructor is called either before or after the QNapiConfig destructor). If one is lucky, the cfg singleton will be destroyed before defaultDateTimePrivate and things will work just fine, but this ordering is not guaranteed. For example, on Arch Linux with Qt 5.7, QNapi will segfault if you invoke it using qnapi -o and then press the Save button in the dialog box.

As sync() is explicitly invoked in QNapiConfig::save(), there is no practical need to call delete for the QSettings instance as the only thing its destructor does is syncing the changes (i.e. it is equivalent to calling sync() explicitly). As QNapiConfig is a singleton, no memory leak is possible here either as the OS will free any resources allocated to the program upon its exit anyway.

However, this issue might be a sign that perhaps the singleton pattern needs to be reimplemented in a safer manner.

[krzemin]

Thanks for elaborating. To be honest I would get rid of all singletons and shared mutable state, but the code is mostly legacy and it's a lot of work.