| Summary: | Crash when plugging in HDMI | ||
|---|---|---|---|
| Product: | [Plasma] KScreen | Reporter: | Pascal d'Hermilly <pascal> |
| Component: | kded | Assignee: | Sebastian Kügler <sebas> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | Keywords: | drkonqi |
| Priority: | NOR | ||
| Version: | 5.5.5 | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | http://commits.kde.org/kscreen/338a781e71ee18c43681356b8ea74e0171c55f6c | Version Fixed In: | 5.6.4 |
| Sentry Crash Report: | |||
|
Description
Pascal d'Hermilly
2016-05-02 12:33:43 UTC
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 |