| Summary: | Dolphin crashes on exit when you specify the --icon command line parameter | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-frameworkintegration | Reporter: | Wolfgang Bauer <wbauer1> |
| Component: | general | Assignee: | kdelibs bugs <kdelibs-bugs> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | crash | CC: | aspotashev, cpigat242, crglasoe, elvis.angelaccio, frank78ac, inssecure, montel, mrbm74, ohtf.xqr |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Add some debug output to KIconLoader | ||
|
Description
Wolfgang Bauer
2016-02-24 16:30:14 UTC
I can confirm this. I wonder if this is related to the recent QString -> QStringLiteral changes. It crashes in the destructor of KIconLoader's mAvailableIcons member, which is a QSet<QString>. Maybe the global static KIconLoader gets destoyed after the library that has the read-only QStringLiteral data has already been unloaded? In that case, it seems likely that the application will crash. This makes me wonder if using QStringLiteral everywhere is really a good idea, since you never know if the QString will end up in a global static object at some point. (In reply to Wolfgang Bauer from comment #0) > I'll try to find out which change exactly causes this. That would be great! Created attachment 97559 [details]
Add some debug output to KIconLoader
I hacked some debug output into KIconLoader::hasIcon(const QString&), to see the address of the internal data for each string, and to the KIconLoader destructor, where I first print the address of a string and then try to print the string itself. This way, I found that the string "dialog-close" is the culprit, which I found with grep in frameworkintegration (src/kstyle/kstyle.cpp). It was made a QStringLiteral in this commit, which was made between 5.16 and 5.17: https://quickgit.kde.org/?p=frameworkintegration.git&a=commit&h=7bbc6c98222eb6db988ed78fc334ad9eef0bb6fb Reverting that commit fixes the crash for me. I'll assign to frameworkintegration and CC Laurent, who committed this change. It seems that we have to think about whether a) Everyone who makes QString -> QStringLiteral replacements should be EXTREMELY careful (which is very difficult, since it is not always obvious if passing a QString to a function will result in the string being stored in a global static object), b) Classes like KIconLoader, which are used as global static objects, should copy all strings that they get to the heap in order to prevent such crashes (which might also be difficult to do consistently). (In reply to Frank Reininghaus from comment #3) > https://quickgit.kde.org/?p=frameworkintegration. > git&a=commit&h=7bbc6c98222eb6db988ed78fc334ad9eef0bb6fb > > Reverting that commit fixes the crash for me. Yes, I found this out myself too meanwhile. Btw, I was wrong, sorry. The crash does not only happen with dolphin, but also other applications (not all though, I couldn't reproduce it with the ones I tried earlier). I've just got a similar stacktrace from Lokalize-15.12.2 with KF 5.20.0. (In reply to Alexander Potashev from comment #5) > I've just got a similar stacktrace from Lokalize-15.12.2 with KF 5.20.0. ===== Application: lokalize (lokalize), signal: Segmentation fault Using host libthread_db library "/lib64/libthread_db.so.1". [Current thread is 1 (Thread 0x7f2caa9f57c0 (LWP 8907))] Thread 2 (Thread 0x7f2ca3fff700 (LWP 8909)): #0 0x00007f2cb6c6baed in poll () from /lib64/libc.so.6 #1 0x00007f2cb22c3f14 in g_main_context_iterate.isra () from /usr/lib64/libglib-2.0.so.0 #2 0x00007f2cb22c402c in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #3 0x00007f2cb7853dcb in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5 #4 0x00007f2cb77fe79b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5 #5 0x00007f2cb764da9c in QThread::exec() () from /usr/lib64/libQt5Core.so.5 #6 0x00007f2cbbaad2c8 in QDBusConnectionManager::run() () from /usr/lib64/libQt5DBus.so.5 #7 0x00007f2cb7653430 in QThreadPrivate::start(void*) () from /usr/lib64/libQt5Core.so.5 #8 0x00007f2cb3d87314 in start_thread () from /lib64/libpthread.so.0 #9 0x00007f2cb6c746dd in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7f2caa9f57c0 (LWP 8907)): [KCrash Handler] #6 0x00007f2cb646bc64 in QHash<QString, QHashDummyValue>::deleteNode2(QHashData::Node*) () from /usr/lib64/libKF5IconThemes.so.5 #7 0x00007f2cb76abd19 in QHashData::free_helper(void (*)(QHashData::Node*)) () from /usr/lib64/libQt5Core.so.5 #8 0x00007f2cb6468b9c in KIconLoader::~KIconLoader() () from /usr/lib64/libKF5IconThemes.so.5 #9 0x00007f2cb6468bf9 in (anonymous namespace)::Q_QGS_globalIconLoader::innerFunction()::Holder::~Holder() () from /usr/lib64/libKF5IconThemes.so.5 #10 0x00007f2cb6bc38f9 in __run_exit_handlers () from /lib64/libc.so.6 #11 0x00007f2cb6bc3945 in exit () from /lib64/libc.so.6 #12 0x00007f2cb6bae85c in __libc_start_main () from /lib64/libc.so.6 #13 0x00000000004790f9 in _start () *** Bug 365794 has been marked as a duplicate of this bug. *** *** Bug 365163 has been marked as a duplicate of this bug. *** Sounds related to https://bugreports.qt.io/browse/QTBUG-50829. In any case, the mentioned patch there fixes the crash for me. *** Bug 374733 has been marked as a duplicate of this bug. *** *** Bug 369798 has been marked as a duplicate of this bug. *** Isn't this fixed upstream? I can't reproduce with Qt 5.9 (In reply to Elvis Angelaccio from comment #12) > Isn't this fixed upstream? I can't reproduce with Qt 5.9 Yes, it should be fixed since 5.8.0 AFAIK. 5.6.2 does not have the fix AFAICS, I have no idea about the upcoming 5.6.3. https://codereview.qt-project.org/#/c/140750/ |