mirror of
https://gitlab.freedesktop.org/wlroots/wlroots.git
synced 2026-02-12 04:28:18 -05:00
30ccac3a02
A footgun in the wlr_buffer API is that there's no difference between acquiring a buffer and increasing the lock count. In other words, transitioning a buffer from the released state to the acquired state is not explicit. This may result in hard-to-debug failures if there is a dangling released wlr_buffer somewhere (e.g. wlr_client_buffer.source [1]) and some piece of code calls wlr_buffer_lock(). In that case, the buffer will be acquired and released again. In the context of a wlr_buffer issued from a Wayland protocol wl_buffer object, this can cause the underlying memory to be used after wl_buffer.release has been sent to the client, and a double wl_buffer.release event to be sent. Make it so acquiring a buffer is an explicit operation to make sure the caller means the state transition and is prepared for a new release event. wlr_buffer_acquire() forbids calls on already-acquired buffers, and wlr_buffer_lock() now forbids calls on released buffers. [1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4904 |
||
|---|---|---|
| .. | ||
| buffer.c | ||
| client.c | ||
| dmabuf.c | ||
| readonly_data.c | ||
| resource.c | ||