Summary: | Coredumps Galore | ||
---|---|---|---|
Product: | [Applications] ring-kde | Reporter: | vindicator <nroycea+kde> |
Component: | general | Assignee: | Emmanuel Lepage Vallée <emmanuel.lepage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
vindicator
2017-08-18 05:19:39 UTC
Two of them (at least, 2 crashes) and about 70 memory leaks have been fixed. It's not to the point where it quits cleanly. Even after this, it probably wont because that QBus connection use-after-free is in a framework. However, slowly getting it to quit in a predictable order cleans the logs. I also generated a valgrind suppression file (that a filter on some memory managment logs) for all the issues that are not in Ring-KDE or LibRingClient. This reduce the noise in the logs and allowed to spots more real issues. The log, at this point, still has about 60000 entries (99.99% of them are false positives). I will keep working on Monday to suppress more false positive until I get a clean log. After that finding the other bugs will be trivial. Also, if anyone is reading this, yes, ASAN *is* enabled. It doesn't catch the problems reported below. At least not on my side. s/Two of them/I fixed 2 of them/ I got a good news and bad news. The first bad news is that I spent a day fixing minor issues in the hope that it would fix itself by quitting in a more orderly order. The other bad news is that nothing was fixed beside some highly unlikely race conditions. After cleaning all the zillion Valgrind false positives (thanks Mesa and QtJS!), I found the root of the issue. The main crash here has nothing to do with any of those stacktraces reported above. The problem is: https://bugreports.qt.io/browse/QTBUG-52988 The good news is that it's fixed. The other bad news is that no distribution has backported the patch yet. I wont change the way the initialization is done because it would break some KDE single instance goodies. As for some other backtraces, I am still investigating, but can't reproduce any of them. Maybe my computer is too fast? What's your hardware? Curious, it says "Fix Version/s: 5.9.0 Alpha", but qtdiag shows Qt 5.9.1 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 7.1.1 20170630) on "xcb" OS: Arch Linux [linux version 4.12.8-2-ARCH] Architecture: x86_64; features: SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 AVX AVX2 ...soooo I'm thinking it would be applied in my version...?... 5.9.1 > 5.9.0 I've had 5.9.1 since 2017-07-06. My hardware: Intel Core i3-4130 8GB RAM I just fetched and rebuilt your ring lrc and kde, opened then closed it with the same kind of result: Stack trace of thread 20337: #0 0x00007f0e41b35690 raise (libpthread.so.0) #1 0x00007f0e425c2fea _ZN6KCrash19defaultCrashHandlerEi (libKF5Crash.so.5) #2 0x00007f0e3b299940 n/a (libc.so.6) Stack trace of thread 20384: #0 0x00007f0e3b349e9d poll (libc.so.6) #1 0x00007f0e368c1c09 n/a (libglib-2.0.so.0) #2 0x00007f0e368c1d1c g_main_context_iteration (libglib-2.0.so.0) #3 0x00007f0e3c1a7084 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5) #4 0x00007f0e3c14affb _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5) #5 0x00007f0e3bf6440e _ZN7QThread4execEv (libQt5Core.so.5) #6 0x00007f0e40fbd96b n/a (libQt5Quick.so.5) #7 0x00007f0e3bf6915b n/a (libQt5Core.so.5) #8 0x00007f0e41b2b049 start_thread (libpthread.so.0) #9 0x00007f0e3b353f0f __clone (libc.so.6) Stack trace of thread 20339: #0 0x00007f0e43507659 _dl_update_slotinfo (ld-linux-x86-64.so.2) #1 0x00007f0e435076bc update_get_addr (ld-linux-x86-64.so.2) #2 0x00007f0e3bf67f67 n/a (libQt5Core.so.5) #3 0x00007f0e3c1a7482 n/a (libQt5Core.so.5) #4 0x00007f0e368c1611 g_main_context_check (libglib-2.0.so.0) #5 0x00007f0e368c1bb0 n/a (libglib-2.0.so.0) #6 0x00007f0e368c1d1c g_main_context_iteration (libglib-2.0.so.0) #7 0x00007f0e3c1a7084 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5) #8 0x00007f0e3c14affb _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5) #9 0x00007f0e3bf6440e _ZN7QThread4execEv (libQt5Core.so.5) #10 0x00007f0e3c5c6396 n/a (libQt5DBus.so.5) #11 0x00007f0e3bf6915b n/a (libQt5Core.so.5) #12 0x00007f0e41b2b049 start_thread (libpthread.so.0) #13 0x00007f0e3b353f0f __clone (libc.so.6) Stack trace of thread 20378: #0 0x00007f0e36906a84 g_mutex_unlock (libglib-2.0.so.0) #1 0x00007f0e368c1abd n/a (libglib-2.0.so.0) #2 0x00007f0e368c1d1c g_main_context_iteration (libglib-2.0.so.0) #3 0x00007f0e3c1a7084 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5) #4 0x00007f0e3c14affb _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5) #5 0x00007f0e3bf6440e _ZN7QThread4execEv (libQt5Core.so.5) #6 0x00007f0e40b7d3d9 n/a (libQt5Qml.so.5) #7 0x00007f0e3bf6915b n/a (libQt5Core.so.5) #8 0x00007f0e41b2b049 start_thread (libpthread.so.0) #9 0x00007f0e3b353f0f __clone (libc.so.6) Umm, it might be another bug on your system. It's very strange/problematic because the backtrace is totally inconclusive (as you already noticed). On my system (still locked to Qt 5.7 as it is the minimum version supported by Ring-KDE), The Qt bug from above is the *only* problem I can see when quitting. Here's a simplified backtrace when Ring-KDE is complited with `-ggdb` and it's debug symbols intact: Application: ring-kde (ring-kde), signal: Segmentation fault Using host libthread_db library "/lib64/libthread_db.so.1". [Current thread is 1 (Thread 0x7f1190357740 (LWP 2622))] Thread 2 (Thread 0x7f118731c700 (LWP 2635)): [KCrash Handler] #6 0x000000003e746e69 in ?? () #7 0x00007f1199eaa080 in QObject::disconnect(QObject const*, char const*, QObject const*, char const*) () from /usr/lib64/libQt5Core.so.5 #8 0x00007f119f7e8d50 in QDBusConnectionPrivate::closeConnection() () from /usr/lib64/libQt5DBus.so.5 #9 0x00007f119f7d5916 in QDBusConnectionManager::run() () from /usr/lib64/libQt5DBus.so.5 #10 0x00007f1199cebffc in QThreadPrivate::start(void*) () from /usr/lib64/libQt5Core.so.5 #11 0x00007f119dda84a4 in start_thread () from /lib64/libpthread.so.0 #12 0x00007f119907870f in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7f1190357740 (LWP 2622)): #0 0x00007f119ddae20f in pthread_cond_wait () from /lib64/libpthread.so.0 #1 0x00007f1199cec64a in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib64/libQt5Core.so.5 #2 0x00007f1199cebc26 in QThread::wait(unsigned long) () from /usr/lib64/libQt5Core.so.5 #3 0x00007f119f7d56a6 in QDBusConnectionManager::~QDBusConnectionManager() () from /usr/lib64/libQt5DBus.so.5 #4 0x00007f119f7d5739 in (anonymous namespace)::Q_QGS__q_manager::innerFunction()::Holder::~Holder() () from /usr/lib64/libQt5DBus.so.5 #5 0x00007f1198fc5b80 in __run_exit_handlers () from /lib64/libc.so.6 #6 0x00007f1198fc5bda in exit () from /lib64/libc.so.6 #7 0x00007f1198fb02c7 in __libc_start_main () from /lib64/libc.so.6 #8 0x000000000046adfa in _start () If I mitigate that one, it quits cleanly (without memory leaks and in an orderly fashion). The backtrace you report above could have been caused by this issue as it could have trashed the heap and caused random backtraces unrelated to Ring-KDE. However, that theory goes down the hole if you have Qt 5.9.1... I got a Dockerfile for Arch to test the build, but it doesn't help with this issue as it is clearly a bug *in something else* that leaks into Ring-KDE and cause it to crash. I will need to install a full Virtual Machine and investigate. It still worth understanding/fixing even if it's not in Ring-KDE itself, but as Arch have terrible support for debug symbols, it wont be easy... One thing I would appreciate if you could try is (in a terminal): export QMLSCENE_DEVICE=softwarecontext QMLSCENE_DEVICE=softwarecontext ring-kde before executing Ring-KDE. That should help detect if the bug is in the video driver. If it is, there's nothing I can do. I hope it's not, as having a crashy 3.0 release on system similar to use would be catastrophic... If that doesn't work, the next step (assuming I can't reproduce) will be using valgrind on your system. Are you familiar with valgrind? Fixed in LRC commits: f975033 90451b2 6c15860 d07e479 c0248f5 34a11bd b049fa4 b68614b 5b654eb 93069ba 27e80f3 9f54972 20a8d84 919a265 51c21ad b9d3bcb 80a0c7f 521b4bc d1d6634 4f218ef 13d9703 6f66fad 1822fa0 d72d617 5efe711 and Ring-KDE commits: fb1d7dbd 4d5ec519 3a4d490c 6794cb12 c195481b Work done: * Clean all false positive Valgrind issues using a suppression file * Fix all minor errors detected * Use Valgrind to redesign the destructor order * Fix all memory leaks * Use a GDB script to map the static initialization and destruction order * Rework the static initialization to ban all QObject from being created before main() * Mitigate https://bugreports.qt.io/browse/QTBUG-52988 by moving back the QApplication into main * Mitigate https://bugreports.qt.io/browse/QTBUG-40745 by manually deleting some tree object before QObject::deleteAllChildren * Mitigate https://bugreports.qt.io/browse/QTBUG-43080 by being more careful to free the QML engine early * Implement the QWidget closeEvent for the timelinewindow to make sure the application quits sanely when using either the QAction or X11 events. |