Application: kdeinit5 () Qt Version: 5.5.1 Operating System: Linux 4.4.0-21-generic x86_64 Distribution: Ubuntu 16.04 LTS -- Information about the crash: - What I was doing when the application crashed: The crash dialogs started appearing when I plugged in HDMI for a 4K TV. If you keep letting it crash, at some point it freezes the computer (at least longer than I wanted to wait.) The crash can be reproduced every time. -- Backtrace: Application: kdeinit5 (kdeinit5), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7fa142b6c740 (LWP 1279))] Thread 7 (Thread 0x7fa12ea7a700 (LWP 1282)): #0 0x00007fa1412b9e8d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x00007fa140996c62 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1 #2 0x00007fa1409988d7 in xcb_wait_for_event () from /usr/lib/x86_64-linux-gnu/libxcb.so.1 #3 0x00007fa130dcc629 in QXcbEventReader::run (this=0x1249740) at qxcbconnection.cpp:1253 #4 0x00007fa14162d84e in QThreadPrivate::start (arg=0x1249740) at thread/qthread_unix.cpp:331 #5 0x00007fa13f0cc6fa in start_thread (arg=0x7fa12ea7a700) at pthread_create.c:333 #6 0x00007fa1412c5b5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 6 (Thread 0x7fa1248a0700 (LWP 1288)): #0 0x00007fa1412b9e8d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x00007fa13e3a231c in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00007fa13e3a242c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x00007fa13e3a2469 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x00007fa13e3c8b45 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x00007fa13f0cc6fa in start_thread (arg=0x7fa1248a0700) at pthread_create.c:333 #6 0x00007fa1412c5b5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 5 (Thread 0x7fa11ffff700 (LWP 1289)): #0 0x00007fa1412b59cd in read () at ../sysdeps/unix/syscall-template.S:84 #1 0x00007fa13e3e56c0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00007fa13e3a1e04 in g_main_context_check () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x00007fa13e3a22c0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x00007fa13e3a26a2 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x00007fa125218906 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 #6 0x00007fa13e3c8b45 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #7 0x00007fa13f0cc6fa in start_thread (arg=0x7fa11ffff700) at pthread_create.c:333 #8 0x00007fa1412c5b5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 4 (Thread 0x7fa116f6a700 (LWP 1316)): #0 0x00007fa1412b59cd in read () at ../sysdeps/unix/syscall-template.S:84 #1 0x00007fa13e3e56c0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00007fa13e3a1e04 in g_main_context_check () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x00007fa13e3a22c0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x00007fa13e3a242c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x00007fa141864a9b in QEventDispatcherGlib::processEvents (this=0x7fa1100008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:420 #6 0x00007fa14180bdea in QEventLoop::exec (this=this@entry=0x7fa116f69e40, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204 #7 0x00007fa1416288a4 in QThread::exec (this=<optimized out>) at thread/qthread.cpp:503 #8 0x00007fa11eade7d7 in KCupsConnection::run() () from /usr/lib/x86_64-linux-gnu/libkcupslib.so #9 0x00007fa14162d84e in QThreadPrivate::start (arg=0x13690b0) at thread/qthread_unix.cpp:331 #10 0x00007fa13f0cc6fa in start_thread (arg=0x7fa116f6a700) at pthread_create.c:333 #11 0x00007fa1412c5b5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 3 (Thread 0x7fa116769700 (LWP 1317)): #0 0x00007fa13e3a2210 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #1 0x00007fa13e3a242c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00007fa141864a9b in QEventDispatcherGlib::processEvents (this=0x7fa1080008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:420 #3 0x00007fa14180bdea in QEventLoop::exec (this=this@entry=0x7fa116768e80, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204 #4 0x00007fa1416288a4 in QThread::exec (this=<optimized out>) at thread/qthread.cpp:503 #5 0x00007fa14162d84e in QThreadPrivate::start (arg=0x1367a10) at thread/qthread_unix.cpp:331 #6 0x00007fa13f0cc6fa in start_thread (arg=0x7fa116769700) at pthread_create.c:333 #7 0x00007fa1412c5b5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 2 (Thread 0x7fa1158ba700 (LWP 1377)): #0 0x00007fa1412b9e8d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x00007fa13e3a231c in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00007fa13e3a242c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x00007fa141864a9b in QEventDispatcherGlib::processEvents (this=0x7fa10c0008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:420 #4 0x00007fa14180bdea in QEventLoop::exec (this=this@entry=0x7fa1158b9e80, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204 #5 0x00007fa1416288a4 in QThread::exec (this=<optimized out>) at thread/qthread.cpp:503 #6 0x00007fa14162d84e in QThreadPrivate::start (arg=0x1309ca0) at thread/qthread_unix.cpp:331 #7 0x00007fa13f0cc6fa in start_thread (arg=0x7fa1158ba700) at pthread_create.c:333 #8 0x00007fa1412c5b5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 1 (Thread 0x7fa142b6c740 (LWP 1279)): [KCrash Handler] #6 0x00007fa12c3d6914 in KScreen::Config::outputs() const () from /usr/lib/x86_64-linux-gnu/libKF5Screen.so.6 #7 0x00007fa12c3d69f3 in KScreen::Config::canBeApplied(QSharedPointer<KScreen::Config> const&, QFlags<KScreen::Config::ValidityFlag>) () from /usr/lib/x86_64-linux-gnu/libKF5Screen.so.6 #8 0x00007fa12614fc80 in KScreenDaemon::applyKnownConfig (this=0x130f730) at /build/kscreen-bu2ABG/kscreen-5.5.5/kded/daemon.cpp:169 #9 0x00007fa12614fe85 in KScreenDaemon::applyConfig (this=0x130f730) at /build/kscreen-bu2ABG/kscreen-5.5.5/kded/daemon.cpp:156 #10 0x00007fa14183ce4f in QtPrivate::QSlotObjectBase::call (a=0x7ffcb01ff370, r=0x130f730, this=<optimized out>) at ../../include/QtCore/../../src/corelib/kernel/qobject_impl.h:124 #11 QMetaObject::activate (sender=sender@entry=0x130fa10, signalOffset=<optimized out>, local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x0) at kernel/qobject.cpp:3698 #12 0x00007fa14183d7d7 in QMetaObject::activate (sender=sender@entry=0x130fa10, m=m@entry=0x7fa141a57840 <QTimer::staticMetaObject>, local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x0) at kernel/qobject.cpp:3578 #13 0x00007fa1418bc6d0 in QTimer::timeout (this=this@entry=0x130fa10) at .moc/moc_qtimer.cpp:197 #14 0x00007fa141849878 in QTimer::timerEvent (this=0x130fa10, e=<optimized out>) at kernel/qtimer.cpp:247 #15 0x00007fa14183de53 in QObject::event (this=0x130fa10, e=<optimized out>) at kernel/qobject.cpp:1261 #16 0x00007fa14025705c in QApplicationPrivate::notify_helper (this=this@entry=0x1229bd0, receiver=receiver@entry=0x130fa10, e=e@entry=0x7ffcb01ff6a0) at kernel/qapplication.cpp:3716 #17 0x00007fa14025c516 in QApplication::notify (this=0x7ffcb01ff9e0, receiver=0x130fa10, e=0x7ffcb01ff6a0) at kernel/qapplication.cpp:3499 #18 0x00007fa14180e62b in QCoreApplication::notifyInternal (this=0x7ffcb01ff9e0, receiver=0x130fa10, event=event@entry=0x7ffcb01ff6a0) at kernel/qcoreapplication.cpp:965 #19 0x00007fa14186389d in QCoreApplication::sendEvent (event=0x7ffcb01ff6a0, receiver=<optimized out>) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:224 #20 QTimerInfoList::activateTimers (this=0x1267750) at kernel/qtimerinfo_unix.cpp:637 #21 0x00007fa141863da1 in timerSourceDispatch (source=<optimized out>) at kernel/qeventdispatcher_glib.cpp:177 #22 0x00007fa13e3a2127 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #23 0x00007fa13e3a2380 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #24 0x00007fa13e3a242c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #25 0x00007fa141864a7f in QEventDispatcherGlib::processEvents (this=0x1266920, flags=...) at kernel/qeventdispatcher_glib.cpp:418 #26 0x00007fa14180bdea in QEventLoop::exec (this=this@entry=0x7ffcb01ff8e0, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204 #27 0x00007fa141813e8c in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1229 #28 0x00007fa130e8826d in kdemain () from /usr/lib/x86_64-linux-gnu/libkdeinit5_kded5.so #29 0x000000000040858c in ?? () #30 0x00000000004059fc in main () Reported using DrKonqi
Thanks for the report! The backtrace doesn't really help here, to debug this further, I'd need some additional information and the config files kscreen creates (these can hopefully give us a pointer why the kded module crashes. Could you paste the contents of the files in ~/.local/share/kscreen/ here? Could you paste the output of "kscreen-console outputs"? Could you enable detailed logging by putting this into your ~/.config/QtProject/qtlogging.ini [Rules] kscreen.kded=true and then reproduce the crash with by stopping and restarting kded5 from a terminal, so you get its output: kquitapp kded5 kded5 (as your normal user). In order to work around the crash on your system, so you can use it, try moving the files in ~/.local/share/kscreen/ out of the way (keep backups, just in case), if it still crashes (it probably will) disable the "KScreen 2" module in System Settings > Startup and Shutdown > Background Services from Startup Services. Thanks for the help!
I've tried to get all the information you asked for. https://dhermilly.dk/owncloud/index.php/s/2L4k7NNh46jnUyu Paste in what you like here. It was hard since the whole system would freeze when HDMI was plugged in (attached a kern.log) Starting it with HDMI in works, but produced the crashes. Now though, I think after the qtlogging thing was enabled, it doesn't crash kded.
Very good, thanks a lot for collecting the info. It will take me some time to sift through it. Would it be possible for you to try also against Qt 5.6?
>Would it be possible for you to try also against Qt 5.6? If it's available on a live CD. My plan is to try out the KDE Neon thing when things have stabilized a bit - But I think I read that it also runs qt 5.5
It has actually just been updated to Qt 5.6. It would be really helpful to verify against that, especially since much multiscreen headache was fixed in Qt 5.6. If you try it, get the developer edition right away. Thanks!
For some reason i'm not able to boot from my flashed live-usb. Tried two different sticks, dd and usb-creator. Can I test with both the developer stable and unstable?
Yes, both are helpful. But then, I have a patch ready that's probably going to fix your crash: https://phabricator.kde.org/D1533
Git commit d80fedea86d613c4039f543a898f177e887d22c4 by Sebastian Kügler. Committed on 06/05/2016 at 12:00. Pushed by sebas into branch 'master'. validate the config before checking if it can be applied Summary: canBeApplied is public API, it shouldn't blow up when passed an invalid config, but indicate (correctly!) that this "config" can't be applied. This is called a bit carelessly from the kded daemon. I've fixed it there as well, but it seems prudent to also make sure in libkscreen that the user doesn't do stupid things. Test Plan: autotests pass Reviewers: #plasma, graesslin Reviewed By: #plasma, graesslin Subscribers: graesslin, plasma-devel Projects: #plasma Differential Revision: https://phabricator.kde.org/D1532 M +3 -0 autotests/testscreenconfig.cpp M +4 -0 src/config.cpp http://commits.kde.org/libkscreen/d80fedea86d613c4039f543a898f177e887d22c4
Git commit 5e55fd1e0e8aa8379d67101822b1ca8954d7f18f by Sebastian Kügler. Committed on 06/05/2016 at 12:01. Pushed by sebas into branch 'Plasma/5.6'. validate the config before checking if it can be applied Summary: canBeApplied is public API, it shouldn't blow up when passed an invalid config, but indicate (correctly!) that this "config" can't be applied. This is called a bit carelessly from the kded daemon. I've fixed it there as well, but it seems prudent to also make sure in libkscreen that the user doesn't do stupid things. Test Plan: autotests pass Reviewers: #plasma, graesslin Reviewed By: #plasma, graesslin Subscribers: graesslin, plasma-devel Projects: #plasma Differential Revision: https://phabricator.kde.org/D1532 M +3 -0 autotests/testscreenconfig.cpp M +4 -0 src/config.cpp http://commits.kde.org/libkscreen/5e55fd1e0e8aa8379d67101822b1ca8954d7f18f
Git commit 3cd5c74d5523b2f2b2e95174dbaf7ece10d74a50 by Sebastian Kügler. Committed on 06/05/2016 at 12:03. Pushed by sebas into branch 'master'. guard access to unsafe config pointer Summary: This fixes a crashing race condition in the kscreen kded module when the config cannot be deserialized from the filesystem. In this case, Serializer returns a nullptr which is then derefenced without validation. In practice, we just can't be sure the file can be read, so we need to make sure that we're not passing configs around which may be empty. Down the road, I think we should be a bit more careful also in libkscreen, there's some API that can receive ConfigPtrs, which aren't validated before dereferencing. FIXED-IN:5.6.4 CHANGELOG:Fix crasher in kscreen kded daemon Test Plan: Can't really test this scenario, since I can't reproduce the crash. All testing I've done passes, and I've added a bunch of autotests for invalid configs (separate commit) Reviewers: #plasma, graesslin Reviewed By: #plasma, graesslin Subscribers: graesslin, plasma-devel Projects: #plasma Differential Revision: https://phabricator.kde.org/D1533 M +2 -1 kded/daemon.cpp http://commits.kde.org/kscreen/3cd5c74d5523b2f2b2e95174dbaf7ece10d74a50
Git commit 338a781e71ee18c43681356b8ea74e0171c55f6c by Sebastian Kügler. Committed on 06/05/2016 at 12:03. Pushed by sebas into branch 'Plasma/5.6'. guard access to unsafe config pointer Summary: This fixes a crashing race condition in the kscreen kded module when the config cannot be deserialized from the filesystem. In this case, Serializer returns a nullptr which is then derefenced without validation. In practice, we just can't be sure the file can be read, so we need to make sure that we're not passing configs around which may be empty. Down the road, I think we should be a bit more careful also in libkscreen, there's some API that can receive ConfigPtrs, which aren't validated before dereferencing. FIXED-IN:5.6.4 CHANGELOG:Fix crasher in kscreen kded daemon Test Plan: Can't really test this scenario, since I can't reproduce the crash. All testing I've done passes, and I've added a bunch of autotests for invalid configs (separate commit) Reviewers: #plasma, graesslin Reviewed By: #plasma, graesslin Subscribers: graesslin, plasma-devel Projects: #plasma Differential Revision: https://phabricator.kde.org/D1533 M +2 -1 kded/daemon.cpp http://commits.kde.org/kscreen/338a781e71ee18c43681356b8ea74e0171c55f6c