cursor interactions cause lockup with pocket desktop
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mir |
Invalid
|
High
|
Kevin DuBois | ||
qtdeclarative-opensource-src (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
qtmir (Ubuntu) |
Invalid
|
Undecided
|
Daniel d'Andrada | ||
unity8 (Ubuntu) |
Fix Released
|
Undecided
|
Daniel d'Andrada |
Bug Description
To reproduce (seen on frieza):
Connect a mouse to a pocket desktop setup.
Launch a 'legacy' application, like gedit, in windowed mode. The problem is not seen with 'native' applications, it seems that the setting the custom cursor bitmap that Xmir does is the precipitating event for the problem.
Rapidly move the cursor over the edge of the window to force rapid cursor transitions.
After a while (usually between 30s-2 minutes of the rapid movement), the desktop will lock up.
First noted on mir 0.23 testing (silo 69), but also seen with 0.22.1.
USC is still alive, and doesn't look locked up. Unity8 is locked.
Render logs from Qt for the last 2 frames (including the one that's locked)
http://
BT of threads when attaching to unity8 when stuck:
http://
note: it seems that thread 1 is the render loop, and thread 2 is the render thread. Thread 2 doesn't quite seem stuck (seems to be busy, and doesnt unblock), and thread 1 is stuck waiting for a response from thread 2
If I disable the notification of the cursor change callback in mir (just commenting out here)
http://
This breaks the cursor updating for Xmir apps, but averts the crash
Related branches
- Unity8 CI Bot: Needs Fixing (continuous-integration)
- Albert Astals Cid (community): Approve
-
Diff: 60 lines (+2/-16)2 files modifiedplugins/Cursor/CursorImageInfo.cpp (+2/-12)
plugins/Cursor/CursorImageInfo.h (+0/-4)
Changed in qtmir: | |
assignee: | nobody → Daniel d'Andrada (dandrader) |
description: | updated |
Changed in qtmir: | |
status: | New → In Progress |
affects: | qtmir → qtmir (Ubuntu) |
not quite sure if its a mir problem or a qtmir+u8 problem, so will tag both.