I'm trying to debug a crash (http://sourceforge.net/p/launchy/bugs/432/) that occurs in launchy (http://www.launchy.net/), which seems to be a pure-qt application, unaware of KDE libraries. Before crashing, it emits KGlobal::locale() must be called from the main thread before using i18n() in threads. KApplication takes care of this. If not using KApplication, call KGlobal::locale() during initialization. Program received signal SIGABRT, Aborted. and the backtrace is #0 0x00007ffff5d33037 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007ffff5d36698 in __GI_abort () at abort.c:90 #2 0x00007ffff664e5c2 in qt_message_output (msgType=msgType@entry=QtFatalMsg, buf=0x7fffd406f518 "KGlobal::locale() must be called from the main thread before using i18n() in threads. KApplication takes care of this. If not using KApplication, call KGlobal::locale() during initialization.") at global/qglobal.cpp:2347 #3 0x00007ffff664e938 in qt_message(QtMsgType, const char *, typedef __va_list_tag __va_list_tag *) (msgType=msgType@entry=QtFatalMsg, msg=msg@entry=0x7fffef0d1a70 "KGlobal::locale() must be called from the main thread before using i18n() in threads. KApplication takes care of this. If not using KApplication, call KGlobal::locale() during initialization.", ap=ap@entry=0x7fffdfb70778) at global/qglobal.cpp:2393 #4 0x00007ffff664eac4 in qFatal ( msg=msg@entry=0x7fffef0d1a70 "KGlobal::locale() must be called from the main thread before using i18n() in threads. KApplication takes care of this. If not using KApplication, call KGlobal::locale() during initialization.") at global/qglobal.cpp:2576 #5 0x00007fffeefd6efd in KGlobal::locale () at ../../kdecore/kernel/kglobal.cpp:192 #6 0x00007fffeeff2358 in KMimeTypePrivate::ensureXmlDataLoaded (this=this@entry=0x7fffd4029fa0) at ../../kdecore/services/kmimetype.cpp:634 #7 0x00007fffeeff43a8 in KMimeTypePrivate::iconName (this=0x7fffd4029fa0) at ../../kdecore/services/kmimetype.cpp:791 #8 0x00007fffeeff084e in KMimeType::iconName (this=<optimized out>, url=...) at ../../kdecore/services/kmimetype.cpp:605 #9 0x00007fffefe405dc in KQGuiPlatformPlugin::fileSystemIcon (this=<optimized out>, file=...) at ../../qguiplatformplugin_kde/qguiplatformplugin_kde.cpp:179 #10 0x00007ffff75645a9 in QFileIconProvider::icon (this=<optimized out>, info=...) at itemviews/qfileiconprovider.cpp:405 #11 0x0000000000444747 in ?? () #12 0x0000000000444dfd in ?? () #13 0x00007ffff6658bec in QThreadPrivate::start (arg=0x7a0790) at thread/qthread_unix.cpp:338 #14 0x00007ffff548af8e in start_thread (arg=0x7fffdfb71700) at pthread_create.c:311 #15 0x00007ffff5df5e1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 The problem seems to be that QFileIconProvider::icon forwards the request to the KDE platform plugin, with, in the end, forwards it all the way up to KMimeTypePrivate::iconName; the method ensureXMLDataLoaded then tries to do some stuff with the current locale: const QStringList languageList = KGlobal::locale()->languageList(); (at https://projects.kde.org/projects/kde/kdelibs/repository/entry/kdecore/services/kmimetype.cpp?rev=KDE%2F4.10#L634 ) but calling KGlobal::locale() for the first time from a non-main thread results in the fatal error shown above. The problem here is that a "pure" Qt application can neither use KApplication, nor call KGlobal::locale() at initialization - since it does not know anything about KDE in first place. IMHO a "quick & dirty" solution could be to add a call to KGlobal::locale() in the constructor of KQGuiPlatformPlugin - if it's guaranteed to be called in the main thread - or in some other KDE hook in Qt initialization. This would ensure that the locale stuff is always ready, avoiding this crash and potentially other stuff that may occur in similar situations. Reproducible: Always Steps to Reproduce: Under KDE (=with KQGuiPlatformPlugin working), call QFileIconProvider::icon in a non-main thread, asking for an icon of a file in the filesystem. Actual Results: Crash with message KGlobal::locale() must be called from the main thread before using i18n() in threads. KApplication takes care of this. If not using KApplication, call KGlobal::locale() during initialization. Expected Results: No crash, icon returned
A brief testcase: https://bitbucket.org/mitalia/kdebug322901 The application creates a separate thread and uses QFileIconProvider::icon from it; launching the application without parameters under Qt 4.8 with KDE integration results in the crash described above. Instead, if you specify "workaround" as command-line parameter, the program calls QFileIconProvider::icon first in the main thread, which indirectly triggers the missing KGlobal::locale() call and avoids the crash.
Also, targeting my local Qt 5.1 *without* KDE integration does not result in any problem.
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Andrew, I understand that this is probably an automated post, part of the bugtracker cleanup, but it seriously feels like mockery. The bug has been "stagnant for a long time" because you (not you personally, buy "you KDE people") completely ignored it. I investigated the problem, I reduced it to a minimal test case that always exhibited the problem, and even proposed a possible fix; I don't think I could have done anything more than this, yet nobody even bothered to reply, as it's been my experience in general on KDE's bugtracker. That being said, I re-tested on an Ubuntu 17.10 with KDE 5.10.5, and the problem seems to be resolved; probably this particular bug wasn't included in the umpteenth rewrite of the core libraries; have a good day.