This repository has been archived by the owner on Nov 1, 2021. It is now read-only.
Crash on types/wlr_buffer.c:52: wlr_buffer_unlock: Assertion `buffer->n_locks > 0' failed #2941
Labels
Comments
|
I recorded the function call stack of this buffer when unlock was called the last two times. The first:
Second(crash):
|
zccrs
added a commit
to zccrs/wlroots
that referenced
this issue
May 28, 2021
In the wlr_buffer_unlock, when the dropped of buffer is false and the n_locks is 0 that not call the buffer_consider_destroy. After that, if wlr_buffer_unlock is called again, "assert(buffer->n_locks> 0)" will fail. Fixes: swaywm#2941
zccrs
added a commit
to zccrs/wlroots
that referenced
this issue
May 29, 2021
In the wlr_buffer_unlock, when the dropped of buffer is false and the n_locks is 0 that not call the buffer_consider_destroy. So in the gles2_texture_unref, should be check the buffer released state on call wlr_buffer_unlock before. Fixes: swaywm#2941
emersion
added a commit
to emersion/wlroots
that referenced
this issue
May 29, 2021
When importing a DMA-BUF wlr_buffer as a wlr_texture, the GLES2 renderer caches the result, in case the buffer is used for texturing again in the future. When the wlr_texture is destroyed by the caller, the wlr_buffer is unref'ed, but the wlr_gles2_texture is kept around. This is fine because wlr_gles2_texture listens for wlr_buffer's destroy event to avoid any use-after-free. However, with this logic wlr_texture_destroy doesn't "really" destroy the wlr_gles2_texture. It just decrements the wlr_buffer ref'count. Each wlr_texture_destroy call must have a matching prior wlr_texture_create_from_buffer call or the ref'counting will go south. Wehn destroying the renderer, we don't want to decrement any wlr_buffer ref'count. Instead, we want to go through any cached wlr_gles2_texture and destroy our GL state. So instead of calling wlr_texture_destroy, we need to call our internal gles2_texture_destroy function. Closes: swaywm#2941
bl4ckb0ne
pushed a commit
that referenced
this issue
May 30, 2021
When importing a DMA-BUF wlr_buffer as a wlr_texture, the GLES2 renderer caches the result, in case the buffer is used for texturing again in the future. When the wlr_texture is destroyed by the caller, the wlr_buffer is unref'ed, but the wlr_gles2_texture is kept around. This is fine because wlr_gles2_texture listens for wlr_buffer's destroy event to avoid any use-after-free. However, with this logic wlr_texture_destroy doesn't "really" destroy the wlr_gles2_texture. It just decrements the wlr_buffer ref'count. Each wlr_texture_destroy call must have a matching prior wlr_texture_create_from_buffer call or the ref'counting will go south. Wehn destroying the renderer, we don't want to decrement any wlr_buffer ref'count. Instead, we want to go through any cached wlr_gles2_texture and destroy our GL state. So instead of calling wlr_texture_destroy, we need to call our internal gles2_texture_destroy function. Closes: #2941
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Steps:
tinywl/tinywl.cmain function to:add a new line code: "wlr_backend_destroy(server.backend);"
the log:
The text was updated successfully, but these errors were encountered: