The xcb_connection_t instance that is used here comes from
XGetXCBConnection(), is created by XOpenDisplay(), and is owned by the
returned Display*. Calling xcb_disconnect() directly on it leads to
various use-after-frees during shutdown, as reported by valgrind. The
first one of the about 30 errors is:
Invalid read of size 4
at 0x71F2051: xcb_take_socket (in /usr/lib64/libxcb.so.1.1.0)
by 0x78551DD: ??? (in /usr/lib64/libX11.so.6.3.0)
by 0x7855A14: _XFlush (in /usr/lib64/libX11.so.6.3.0)
by 0x7858504: _XGetRequest (in /usr/lib64/libX11.so.6.3.0)
by 0x7838966: XFreeGC (in /usr/lib64/libX11.so.6.3.0)
by 0x783238B: XCloseDisplay (in /usr/lib64/libX11.so.6.3.0)
by 0x4E680C2: wlr_x11_backend_destroy (backend.c:333)
by 0x4E57E94: wlr_backend_destroy (backend.c:39)
by 0x4E629FB: multi_backend_destroy (backend.c:47)
by 0x4E62B5A: handle_display_destroy (backend.c:90)
by 0x50B7E9F: ??? (in /usr/lib64/libwayland-server.so.0.1.0)
by 0x50B8476: wl_display_destroy (in /usr/lib64/libwayland-server.so.0.1.0)
Address 0xc14dda0 is 0 bytes inside a block of size 21,152 free'd
at 0x4C2DD18: free (vg_replace_malloc.c:530)
by 0x4E680A5: wlr_x11_backend_destroy (backend.c:330)
by 0x4E57E94: wlr_backend_destroy (backend.c:39)
by 0x4E629FB: multi_backend_destroy (backend.c:47)
by 0x4E62B5A: handle_display_destroy (backend.c:90)
by 0x50B7E9F: ??? (in /usr/lib64/libwayland-server.so.0.1.0)
by 0x50B8476: wl_display_destroy (in /usr/lib64/libwayland-server.so.0.1.0)
by 0x40C54E: main (main.c:84)
Block was alloc'd at
at 0x4C2EA1E: calloc (vg_replace_malloc.c:711)
by 0x71F0C60: xcb_connect_to_fd (in /usr/lib64/libxcb.so.1.1.0)
by 0x71F4BD4: xcb_connect_to_display_with_auth_info (in /usr/lib64/libxcb.so.1.1.0)
by 0x7854AA1: _XConnectXCB (in /usr/lib64/libX11.so.6.3.0)
by 0x7845481: XOpenDisplay (in /usr/lib64/libX11.so.6.3.0)
by 0x4E681B6: wlr_x11_backend_create (backend.c:376)
by 0x4E580EE: wlr_backend_autocreate (backend.c:99)
by 0x40C27D: main (main.c:35)
Normally, one would expect this to crash during XCloseDisplay() when
xcb_disconnect() is called again and frees the same data again (glibc would
detect a double free). However, XCloseDisplay() tries to clean up some internal
caches first for which it has to send requests to the X11 server (e.g. the
XFreeGC() above). This fails since the file descriptor was already closed,
which causes an IO error. Xlib's _XDefaultIOError() handles this by printing an
error message and calling exit(1).
Thus, the only symptom of this problem was compositors exiting
mid-shutdown and printing an error message:
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
after 6 requests (6 known processed) with 0 events remaining.
Fixes: https://github.com/swaywm/wlroots/issues/745
Signed-off-by: Uli Schlachter <psychon@znc.in>
- Textures are now immutable (apart from those created from raw
pixels), no more invalid textures
- Move all wl_drm stuff in wlr_renderer
- Most of wlr_texture fields are now private
- Remove some duplicated DMA-BUF code in the DRM backend
- Add more assertions
- Stride is now always given as bytes rather than pixels
- Drop wl_shm functions
Fun fact: this patch has been written 10,000 meters up in the air.
==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)
The current mode was set to NULL to abuse it as state variable
persisting DRM suspend/resume, this results resulted in a segfault on
normal DPMS cycle.
This reverts that change and uses the wlr_output enabled variable, which
also persists and makes more sense.
Legacy gamma lut size now uses the new legacy_crtc member of
wlr_drm_crtc. This was Previously doen using old_crtc in
wlr_drm_connector, but since this refers to the crtc that was connected to
the ouput, this could give the wrong result.
On the drm output the wlr_drm_connector structs are reused.
This struct contains the wlr_output struct, which is reused as well.
The old code kept modes/edid and output state persistent over hotplug.
This nulls the relevant strings, reads newer edid data and removes old
modes on unplug.
The backend destroy signal is emitted before the output_remove
signal is. When the destroy signal is emitted listeners remove
their output_remove listener, so the output_remove signal is never
received and listeners have an invalid output pointer.
The correct way to solve this would be to remove the output_remove
signal completely and use the wlr_output.events.destroy signal
instead. This isn't yet possible because wl_signal_emit is unsafe
and listeners cannot be removed in listeners.
The wlr_drm_surface_init function is called (upon others) when the drm
mode is changed.
When the surface was used previously this replaced the gbm_surface, but
did not replace the gbm buffers (front/back).
With this, wlr_drm_surface_get_from never set up the new buffers with
the new glViewport because surf->front existed.
This frees the buffers to get new buffers on the new surface with the
new viewport.
Right now, we are adding systemd and elogind backends to the build
system as soon as their libraries are found on the build system.
Instead, we should only add them if the libraries have been found _and_
the user has actually requested them to be included.
since we're looking at pointer differences.
Otherwise the build fails on arm like
In file included from ../backend/drm/drm.c:19:0:
../include/wlr/util/log.h:34:17: error: format '%jd' expects argument of type 'intmax_t', but argument 7 has type 'int' [-Werror=format=]
_wlr_log(verb, "[%s:%d] " fmt, _strip_path(__FILE__), __LINE__, ##__VA_ARGS__)
^
../backend/drm/drm.c:462:2: note: in expansion of macro 'wlr_log'
wlr_log(L_DEBUG, "%s: crtc=%ju ovr=%jd pri=%jd cur=%jd", conn->output.name,
^~~~~~~
../backend/drm/drm.c:462:39: note: format string is defined here
wlr_log(L_DEBUG, "%s: crtc=%ju ovr=%jd pri=%jd cur=%jd", conn->output.name,
~~^
%d
