Summary: | ShellCorona::reconsiderOutput crashes on first boot | ||
---|---|---|---|
Product: | [Plasma] plasmashell | Reporter: | Jason Bradley Smith <jbssrepairs> |
Component: | general | Assignee: | Sebastian Kügler <sebas> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | bhush94, don.waterloo+kde, nadavkav, plasma-bugs, sebas |
Priority: | NOR | Keywords: | drkonqi |
Version: | 5.2.2 | ||
Target Milestone: | 1.0 | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | http://commits.kde.org/plasma-workspace/8e12bd4bdee86fabc3e2985922aae73916cef700 | Version Fixed In: | 5.3.1 |
Sentry Crash Report: |
Description
Jason Bradley Smith
2015-04-24 19:44:14 UTC
*** Bug 346407 has been marked as a duplicate of this bug. *** *** Bug 346766 has been marked as a duplicate of this bug. *** Looks like a race condition in the startup-multiscreen dance. Proposed patch: https://git.reviewboard.kde.org/r/123648/ Git commit 8e12bd4bdee86fabc3e2985922aae73916cef700 by Sebastian Kügler. Committed on 05/05/2015 at 23:56. Pushed by sebas into branch 'Plasma/5.3'. Guard access to kscreen configuration reconsiderOutputs() may be called before the async config fetching operation (KScreen::GetConfigOperation) has finished, so the pointer is still null at that point. This can happen if qApp::screenRemoved fires before kscreen was able to start the backend loader and pass back a ConfigPtr. The bug is rooted by in the dual-use of libkscreen and qApp's QScreen handling. The timings here produce this race condition. This patch should be quite safe, though, since it doesn't change the logic, but rather makes sure this race condition bails out nicely by falling back to just waiting until a kscreen config has arrived (which will happen right after). REVIEW:123648 FIXED-IN:5.3.1 CHANGELOG:Fix crash on Plasma startup caused by a race condition M +4 -2 shell/shellcorona.cpp http://commits.kde.org/plasma-workspace/8e12bd4bdee86fabc3e2985922aae73916cef700 |