QApplication and QSettings ordering hang
-
On my system, creating a QSettings object before creating the QApplication object causes the application to hang. In the reverse order no problems are observed. I don't think this is a problem with other systems, as I see source code that works for others that uses that ordering.
I am using Qt 4.7.4 on Gentoo Linux on 64-bit AMD/Intel.
Here is the simplest sample code that fails for me:
@#include <QtGui/QApplication>
#include <QtCore/QSettings>int main(int argc, char** argv) {
QSettings settings("test", "test");
QApplication application(argc, argv);
return 0;
}
@If I strace the resulting program, it hangs on a line like the following:
@futex(0x16bf29c, FUTEX_WAIT_PRIVATE, 1, NULL@
Does anybody know what might be causing this?
-
-
I figured that others may not be able to reproduce the problem, which is why I was wondering what on my system might be causing this.
I am not personally wanting to instantiate the QApplication after the settings, but one of the applications I have been modifying (Luminance HDR) was recently patched to have this ordering and stopped working on my system. Obviously this ordering worked for the devs, so I was trying to figure out if the issue was with me or if the ordering should be reversed. By your comment I would guess it should ideally be reversed, even though it works for others.
-
I am having an issue that may be rooted in use of QSettings objects as well. I have 2 QSettings objects in my application. They are instantiated using IniFormat and used to present some content from 2 .ini files in a setup application. If user changes settings from those presently in the .ini files, the changes are copied back to the .ini files. I do not see anything akin to a "close" or "flush" method for QSettings. I do call the sync() method of both objects (despite the notes in documentation that the destructor calls these) prior to closing the setup app. The problem is that sometimes one or both of the .ini files get corrupted
The target is embedded Linux on an ARM platform. If there are any nuances to using QSettings, I'd be happy to learn them!
Best,
John
-
I have the same issue and can reproduce it with the minimal testcase on Alpine Linux.
The applications that needs QSettings before QApplication is rosegarden. They read the style from qsettings and QApplications::setstyle needs to be called before the application constructor.
Chicken and the egg...
Someone have reported it here and has a qsettings patch as suggestion:
http://sourceforge.net/tracker/?func=detail&aid=3168620&group_id=4932&atid=104932I have no idea if this is a proper fix.
@--- src/corelib/io/qsettings.cpp 2010/11/06 01:55:18 1.1
+++ src/corelib/io/qsettings.cpp 2011/02/24 02:15:51
-117,7 +117,7
Q_GLOBAL_STATIC(ConfFileCache, unusedCacheFunc)
Q_GLOBAL_STATIC(PathHash, pathHashFunc)
Q_GLOBAL_STATIC(CustomFormatVector, customFormatVectorFunc)
-Q_GLOBAL_STATIC(QMutex, globalMutex)
+Q_GLOBAL_STATIC_WITH_ARGS(QMutex, globalMutex, (QMutex::Recursive))
static QSettings::Format globalDefaultFormat = QSettings::NativeFormat;#ifndef Q_OS_WIN
@