- child would leak in the workspace_record_pid path
- removing malloc lets us get rid of That Comment nobody seems
to remember what it was about
- we would leak pipe fds on first fork failling
- we didn't return an error if second fork failed
- the final executed process still had both pipe fds
(would show up in /proc/23560/fd in launched programs)
- we would write twice to the pipe if execl failed for some reason
(e.g. if /bin/sh doesn't exist?!)
That event comes from the toplevel and not the surface, so would cause
a use-after-free on destroy if the toplevel got destroyed first:
==5454==ERROR: AddressSanitizer: heap-use-after-free on address 0x6110001ed198 at pc 0x000000472d10 bp 0x7ffc19070a80 sp 0x7ffc19070a70
WRITE of size 8 at 0x6110001ed198 thread T0
#0 0x472d0f in wl_list_remove ../common/list.c:157
#1 0x42e159 in handle_destroy ../sway/desktop/xdg_shell_v6.c:243
#2 0x7fa9e5b28ce8 in wlr_signal_emit_safe ../util/signal.c:29
#3 0x7fa9e5afd6b1 in destroy_xdg_surface_v6 ../types/xdg_shell_v6/wlr_xdg_surface_v6.c:101
#4 0x7fa9e5d98025 in destroy_resource src/wayland-server.c:688
#5 0x7fa9e5d98091 in wl_resource_destroy src/wayland-server.c:705
#6 0x7fa9e27f103d in ffi_call_unix64 (/lib64/libffi.so.6+0x603d)
#7 0x7fa9e27f09fe in ffi_call (/lib64/libffi.so.6+0x59fe)
#8 0x7fa9e5d9bf2c (/lib64/libwayland-server.so.0+0xbf2c)
#9 0x7fa9e5d983de in wl_client_connection_data src/wayland-server.c:420
#10 0x7fa9e5d99f01 in wl_event_loop_dispatch src/event-loop.c:641
#11 0x7fa9e5d98601 in wl_display_run src/wayland-server.c:1260
#12 0x40a2f4 in main ../sway/main.c:433
#13 0x7fa9e527318a in __libc_start_main ../csu/libc-start.c:308
#14 0x40b749 in _start (/opt/wayland/bin/sway+0x40b749)
0x6110001ed198 is located 152 bytes inside of 240-byte region [0x6110001ed100,0x6110001ed1f0)
freed by thread T0 here:
#0 0x7fa9e7c89880 in __interceptor_free (/lib64/libasan.so.5+0xee880)
#1 0x7fa9e5affce9 in destroy_xdg_toplevel_v6 ../types/xdg_shell_v6/wlr_xdg_toplevel_v6.c:23
#2 0x7fa9e5d98025 in destroy_resource src/wayland-server.c:688
previously allocated by thread T0 here:
#0 0x7fa9e7c89e50 in calloc (/lib64/libasan.so.5+0xeee50)
#1 0x7fa9e5b00eea in create_xdg_toplevel_v6 ../types/xdg_shell_v6/wlr_xdg_toplevel_v6.c:427
#2 0x7fa9e27f103d in ffi_call_unix64 (/lib64/libffi.so.6+0x603d)
The toplevel only notifies the compositor on destroy if it was mapped,
so only listen to events at map time.
A flash of background was happening for two reasons:
1) We were using the xsurface's dimensions to check if the surface is
ready, but these are pending dimensions.
2) In my particular setup, the default geometry of the xsurface does not
intersect any output, which prevented it from receiving a frame done
event. This made the transaction time out and the client would only
redraw once it's been rendered.
We were arranging a parent which may have been deleted by the reaper,
which meant the `current` children list of the surviving parent had a
dangling pointer.
Instead, we now reap the workspace.
The view was configured with the container coordinates.
Although they were right on the first configure, they
changed after a XCB_CONFIGURE_REQUEST, when the
border was already drawn.
Rather than allocate a structure and expect callers to free it, take a
pointer to an existing struct as an argument.
This function is no longer called anywhere though.
- fixes a double-free error when access() failed.
- refactor code to make memory managment (alloc/free) more straightforward
- do not bring the temporary wordexp_t struct around
- do not postpone errors handling
Both sway_output and sway_layer_shell listen to wlr's output destroy event,
but sway_layer_shell needs to access into sway_output's data strucure and needs
to be destroyed first.
Resolve this by making sway_layer_shell listen to a new event that happens at
start of sway_output's destroy handler
Fixes this kind of use-after-free:
==1795==ERROR: AddressSanitizer: heap-use-after-free on address 0x612000191ef0 at pc 0x00000048c388 bp 0x7ffe308f0410 sp 0x7ffe308f0400
WRITE of size 8 at 0x612000191ef0 thread T0
#0 0x48c387 in wl_list_remove ../common/list.c:157
#1 0x42196b in handle_destroy ../sway/desktop/layer_shell.c:275
#2 0x7f55cc2549fa in wlr_signal_emit_safe ../util/signal.c:29
#3 0x7f55cc22cf68 in layer_surface_destroy ../types/wlr_layer_shell.c:182
#4 0x7f55cc22d084 in layer_surface_resource_destroy ../types/wlr_layer_shell.c:196
#5 0x7f55cc4ca025 in destroy_resource src/wayland-server.c:688
#6 0x7f55cc4ca091 in wl_resource_destroy src/wayland-server.c:705
#7 0x7f55cc22c3a2 in resource_handle_destroy ../types/wlr_layer_shell.c:18
#8 0x7f55c8ef103d in ffi_call_unix64 (/lib64/libffi.so.6+0x603d)
#9 0x7f55c8ef09fe in ffi_call (/lib64/libffi.so.6+0x59fe)
#10 0x7f55cc4cdf2c (/lib64/libwayland-server.so.0+0xbf2c)
#11 0x7f55cc4ca3de in wl_client_connection_data src/wayland-server.c:420
#12 0x7f55cc4cbf01 in wl_event_loop_dispatch src/event-loop.c:641
#13 0x7f55cc4ca601 in wl_display_run src/wayland-server.c:1260
#14 0x40bb1e in server_run ../sway/server.c:141
#15 0x40ab2f in main ../sway/main.c:432
#16 0x7f55cb97318a in __libc_start_main ../csu/libc-start.c:308
#17 0x408d29 in _start (/opt/wayland/bin/sway+0x408d29)
0x612000191ef0 is located 48 bytes inside of 312-byte region [0x612000191ec0,0x612000191ff8)
freed by thread T0 here:
#0 0x7f55ce3bb880 in __interceptor_free (/lib64/libasan.so.5+0xee880)
#1 0x42f1db in handle_destroy ../sway/desktop/output.c:1275
#2 0x7f55cc2549fa in wlr_signal_emit_safe ../util/signal.c:29
#3 0x7f55cc23b4c2 in wlr_output_destroy ../types/wlr_output.c:284
#4 0x7f55cc1ddc20 in xdg_toplevel_handle_close ../backend/wayland/output.c:235
#5 0x7f55c8ef103d in ffi_call_unix64 (/lib64/libffi.so.6+0x603d)
previously allocated by thread T0 here:
#0 0x7f55ce3bbe50 in calloc (/lib64/libasan.so.5+0xeee50)
#1 0x42f401 in handle_new_output ../sway/desktop/output.c:1308
#2 0x7f55cc2549fa in wlr_signal_emit_safe ../util/signal.c:29
#3 0x7f55cc1d6cbf in new_output_reemit ../backend/multi/backend.c:113
#4 0x7f55cc2549fa in wlr_signal_emit_safe ../util/signal.c:29
#5 0x7f55cc1deac7 in wlr_wl_output_create ../backend/wayland/output.c:327
#6 0x7f55cc1db353 in backend_start ../backend/wayland/backend.c:55
#7 0x7f55cc1bad55 in wlr_backend_start ../backend/backend.c:35
#8 0x7f55cc1d67a0 in multi_backend_start ../backend/multi/backend.c:24
#9 0x7f55cc1bad55 in wlr_backend_start ../backend/backend.c:35
#10 0x40ba8a in server_run ../sway/server.c:136
#11 0x40ab2f in main ../sway/main.c:432
#12 0x7f55cb97318a in __libc_start_main ../csu/libc-start.c:308
Emitting the close event needs to happen before
container_output_destroy, because container_output_destroy sets the
sway_output to NULL and sway_output is used in IPC.
We were freeing the sway_output immediately upon disconnect which left
a dangling pointer in the output's container. It then tried to use the
pointer when the container is freed.
We don't need to store the sway_output in an output's container which is
destroying, so the fix is to set the pointer to NULL and remove the use
in container_free.
Also added an arrange when the output is disconnected for good measure.
Prompts e.g. authentication request from firefox-wayland ought to be
floating.
This is a bit coarse but just fixed size is not enough, here is what
firefox does:
[1285461.363] -> xdg_wm_base@18.get_xdg_surface(new id xdg_surface@68, wl_surface@71)
[1285461.508] -> xdg_surface@68.get_toplevel(new id xdg_toplevel@67)
[1285461.571] -> xdg_toplevel@67.set_parent(xdg_toplevel@37)
[1285461.630] -> xdg_toplevel@67.set_title("Authentication Required")
[1285461.736] -> xdg_toplevel@67.set_app_id("firefox")
...
[1285476.549] xdg_toplevel@67.configure(0, 0, array)
...
[1285502.080] -> xdg_toplevel@67.set_min_size(299, 187)
[1285502.140] -> xdg_toplevel@67.set_max_size(1920, 32767)
This can also be observed with e.g. the open window of gedit
(gedit->open->other documents)
It happened when a view is a grandchild or deeper of the workspace, is
fullscreen, and unmaps. The workspace would not be included in the
transaction and its pointer to the fullscreen view was left dangling.
container_destroy was calling container_reap_empty, which calls
container_destroy and so on. Eventually the original container_destroy
would return a NULL pointer to the caller which caused a crash.
This also fixes an arrange on the wrong container when moving views in
and out of stacks.
Dominique Martinet
emersion
Ryan Dwyer
Rostislav Pehlivanov
Armin Preiml
Thomas Plaçais
Ryan Dwyer
ael-code
Tony Crisci