==12021==ERROR: AddressSanitizer: heap-use-after-free on address 0x617000015698 at pc 0x7f1a9abe1c09 bp 0x7ffe9068f6b0 sp 0x7ffe9068f6a0
WRITE of size 4 at 0x617000015698 thread T0
#0 0x7f1a9abe1c08 in pointer_handle_leave ../backend/wayland/wl_seat.c:40
#1 0x7f1a96ae7d1d in ffi_call_unix64 (/lib64/libffi.so.6+0x5d1d)
#2 0x7f1a96ae768e in ffi_call (/lib64/libffi.so.6+0x568e)
#3 0x7f1a988e0d8a (/lib64/libwayland-client.so.0+0x8d8a)
#4 0x7f1a988dd927 (/lib64/libwayland-client.so.0+0x5927)
#5 0x7f1a988debe3 in wl_display_dispatch_queue_pending (/lib64/libwayland-client.so.0+0x6be3)
#6 0x7f1a9abdd6d6 in dispatch_events ../backend/wayland/backend.c:28
#7 0x7f1a9a968c11 in wl_event_loop_dispatch (/lib64/libwayland-server.so.0+0x9c11)
#8 0x7f1a9a967449 in wl_display_run (/lib64/libwayland-server.so.0+0x8449)
#9 0x418dff in main ../rootston/main.c:81
#10 0x7f1a99b5ef29 in __libc_start_main (/lib64/libc.so.6+0x20f29)
#11 0x4057c9 in _start (/home/shared/wayland/wlroots/build/rootston/rootston+0x4057c9)
0x617000015698 is located 664 bytes inside of 696-byte region [0x617000015400,0x6170000156b8)
freed by thread T0 here:
#0 0x7f1a9af754b8 in __interceptor_free (/lib64/libasan.so.4+0xde4b8)
#1 0x7f1a9abe01ee in wlr_wl_output_destroy ../backend/wayland/output.c:194
#2 0x7f1a9ac12918 in wlr_output_destroy ../types/wlr_output.c:299
#3 0x7f1a9abe061b in xdg_toplevel_handle_close ../backend/wayland/output.c:255
#4 0x7f1a96ae7d1d in ffi_call_unix64 (/lib64/libffi.so.6+0x5d1d)
#5 0x7f1a96ae768e in ffi_call (/lib64/libffi.so.6+0x568e)
#6 0x7f1a988e0d8a (/lib64/libwayland-client.so.0+0x8d8a)
#7 0x7f1a988dd927 (/lib64/libwayland-client.so.0+0x5927)
#8 0x7f1a988debe3 in wl_display_dispatch_queue_pending (/lib64/libwayland-client.so.0+0x6be3)
#9 0x7f1a9abdd6d6 in dispatch_events ../backend/wayland/backend.c:28
#10 0x7f1a9a968c11 in wl_event_loop_dispatch (/lib64/libwayland-server.so.0+0x9c11)
#11 0x7f1a9a967449 in wl_display_run (/lib64/libwayland-server.so.0+0x8449)
#12 0x418dff in main ../rootston/main.c:81
#13 0x7f1a99b5ef29 in __libc_start_main (/lib64/libc.so.6+0x20f29)
#14 0x4057c9 in _start (/home/shared/wayland/wlroots/build/rootston/rootston+0x4057c9)
previously allocated by thread T0 here:
#0 0x7f1a9af75a38 in __interceptor_calloc (/lib64/libasan.so.4+0xdea38)
#1 0x7f1a9abe0703 in wlr_wl_output_create ../backend/wayland/output.c:272
#2 0x7f1a9abdd8eb in wlr_wl_backend_start ../backend/wayland/backend.c:55
#3 0x7f1a9abbeb49 in wlr_backend_start ../backend/backend.c:28
#4 0x7f1a9abd8ce1 in multi_backend_start ../backend/multi/backend.c:24
#5 0x7f1a9abbeb49 in wlr_backend_start ../backend/backend.c:28
#6 0x418c32 in main ../rootston/main.c:58
#7 0x7f1a99b5ef29 in __libc_start_main (/lib64/libc.so.6+0x20f29)
#8 0x4057c9 in _start (/home/shared/wayland/wlroots/build/rootston/rootston+0x4057c9)
Some clients create an xdg_surface, then create an xdg_toplevel,
but don't map it and destroy it right after. The xdg_surface ends
up in a state where it isn't mapped but role-specific resources
have been allocated. xdg_surface_unmap needs to free these
resources without emitting the unmap signal.
By using the same vertex shader and adding alpha to the fragment shader
for external textures we can:
- use alpha blending
- have wlr_gles2_render_texture_with_matrix work with
the GL_TEXTURE_EXTERNAL_OES. So far this failed
since we passed in alpha which was unknown by fragment_src_external
Allow to set the texture target type when generating/binding the
texture. This allows us to attach the texture type to the texture so we
don't have to keep the logic elsewhere.
Tested with
./weston-simple-dmabuf-drm
./weston-simple-dmabuf-drm --import-immediate=1
./weston-simple-dmabuf-drm --y-inverted=1
(and combinations)
Supports only single plane XRGB dmabufs for now.
