Input/event driven clients may freeze indefinitely
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mir |
Fix Released
|
High
|
Daniel van Vugt | ||
mir (Ubuntu) |
Fix Released
|
High
|
Unassigned |
Bug Description
Input/event driven clients may freeze indefinitely. This is a more generalized form of bug 1379685 that can happen with any windowed app too.
The issue is:
if (!ready_
may drop the newest available frame in some cases:
(ready_
So when this happens, we're dropping the latest frame without any guarantees that the client will redraw another. Because a perfectly efficient event-driven app will only redraw when something changes (e.g. input event) and won't redraw just because a new buffer is available. So giving a buffer back to the client won't wake it up.
The simple answer is to ensure you only drop frames when it's proven that you're not dropping the newest one. Because the time to the next frame after that is completely unpredictable and indefinite...
if (ready_
Related branches
- PS Jenkins bot (community): Needs Fixing (continuous-integration)
- Alan Griffiths: Approve
- Alexandros Frantzis (community): Approve
-
Diff: 271 lines (+163/-51)2 files modifiedsrc/server/compositor/buffer_queue.cpp (+71/-43)
tests/unit-tests/compositor/test_buffer_queue.cpp (+92/-8)
- PS Jenkins bot (community): Needs Fixing (continuous-integration)
- Mir development team: Pending requested
-
Diff: 256 lines (+150/-46)3 files modifiedsrc/server/compositor/buffer_queue.cpp (+66/-45)
src/server/compositor/buffer_queue.h (+2/-0)
tests/unit-tests/compositor/test_buffer_queue.cpp (+82/-1)
Changed in mir: | |
milestone: | none → 0.10.0 |
description: | updated |
Changed in mir: | |
assignee: | nobody → Daniel van Vugt (vanvugt) |
Changed in mir: | |
status: | Triaged → In Progress |
Changed in mir: | |
status: | In Progress → Fix Committed |
Changed in mir: | |
status: | Fix Committed → Fix Released |
mir (0.10.0+ 15.04.20150107. 2-0ubuntu1) vivid; urgency=medium