Connect a mouse to a pocket desktop setup.
Launch a 'legacy' application, like gedit, in windowed mode.
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.
BT of threads when attaching to unity8 when stuck: http://pastebin.ubuntu.com/16952340/
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)
To reproduce (seen on frieza):
Connect a mouse to a pocket desktop setup.
Launch a 'legacy' application, like gedit, in windowed mode.
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) pastebin. ubuntu. com/16953202/
http://
BT of threads when attaching to unity8 when stuck: pastebin. ubuntu. com/16952340/
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)
If I disable the notification of the cursor change callback in mir (just commenting out here) bazaar. launchpad. net/~mir- team/mir/ 0.22/view/ head:/src/ server/ scene/basic_ surface. cpp#L693
http://
This breaks the cursor updating for Xmir apps, but averts the crash