demo server locks up in certain scenarios with --disable-overlays false when starting/stopping second clients
Bug #1329868 reported by
Kevin DuBois
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Mir |
Fix Released
|
High
|
Kevin DuBois | ||
| mir (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Bug Description
This bug came up when trying to integrate the overlay work into the greater system. It should not be seen in unity, as unity has overlays disabled.
Basically, if you start a demo server with:
./mir_demo_
and then start two clients, and you see that both were accepted as overlays,
and then start and stop the 2nd client repeatedly, approximately 1/7 times (nex4), the composition loop will block down in the hwc code.
Related branches
lp:~kdub/mir/rw-fences
- PS Jenkins bot (community): Approve (continuous-integration)
- Alexandros Frantzis (community): Approve
- Alan Griffiths: Needs Fixing
- Alberto Aguirre (community): Approve
-
Diff: 525 lines (+127/-63)24 files modifiedinclude/shared/mir/graphics/android/android_native_buffer.h (+7/-4)
include/shared/mir/graphics/android/native_buffer.h (+11/-2)
include/test/mir_test_doubles/mock_android_native_buffer.h (+2/-2)
src/client/android/android_client_buffer.cpp (+1/-1)
src/platform/graphics/android/android_alloc_adaptor.cpp (+1/-1)
src/platform/graphics/android/android_platform.cpp (+1/-1)
src/platform/graphics/android/buffer.cpp (+1/-1)
src/platform/graphics/android/fb_device.cpp (+1/-1)
src/platform/graphics/android/hwc_fb_device.cpp (+1/-1)
src/platform/graphics/android/hwc_layers.cpp (+1/-1)
src/platform/graphics/android/internal_client_window.cpp (+1/-1)
src/platform/graphics/android/interpreter_cache.cpp (+1/-1)
src/shared/graphics/android/android_native_buffer.cpp (+9/-3)
src/shared/graphics/android/mir_native_window.cpp (+1/-1)
src/shared/testdraw/android_graphics_region_factory.cpp (+2/-1)
tests/unit-tests/client/android/test_android_native_window.cpp (+1/-1)
tests/unit-tests/graphics/android/CMakeLists.txt (+1/-1)
tests/unit-tests/graphics/android/test_android_platform.cpp (+2/-2)
tests/unit-tests/graphics/android/test_buffer.cpp (+4/-4)
tests/unit-tests/graphics/android/test_buffer_tex_bind.cpp (+1/-1)
tests/unit-tests/graphics/android/test_hwc_device.cpp (+6/-6)
tests/unit-tests/graphics/android/test_hwc_layers.cpp (+1/-1)
tests/unit-tests/graphics/android/test_interpreter_buffer_cache.cpp (+2/-2)
tests/unit-tests/graphics/android/test_native_buffer.cpp (+68/-23)
Revision history for this message
| Kevin DuBois (kdub) wrote | #1 |
Revision history for this message
| Kevin DuBois (kdub) wrote | #2 |
| Changed in mir: | |
| status: | In Progress → Fix Committed |
| Changed in mir: | |
| milestone: | none → 0.4.0 |
| Changed in mir: | |
| status: | Fix Committed → Fix Released |
Revision history for this message
| Daniel van Vugt (vanvugt) wrote | #3 |
| Changed in mir (Ubuntu): | |
| importance: | Undecided → High |
| status: | New → Fix Released |
To post a comment you must log in.
So basically, what is happening is:
<render 1>
one renderable is accepted as an overlay
fence for first renderable is raised, guaranteeing no one can /write/ to the buffer while hwc is /reading/
<post>
second renderable appears
<render 2>
both surfaces are rejected as on overlay, must be rendered via the fallback renderer
the buffer for the 1st client has not been updated, so the fallback renderer tries to gl_bind_to_texture the buffer.
the buffer waits on the fence indefinitely, as the hwc will never signal the fence until the next set() is called.
~~~~~~~
So, since both the hwc usage and the texture binding is a read-only operation, we're safe to allow the texture read while the buffer's fence is guarding a read-only operation.