If there are no arguments or invalid arguments given, swaynag will free
`swaynag.details.button_details` under the `cleanup` label in main. It
then called `swaynag_destroy`, which would attempt to free it again.
Since `swaynag.details.button_details` is either freed on line 106 of
main (when there is no detailed message) or added to `swaynag.buttons`
on line 103 of main, there is no reason to manually free it in
`swaynag_destroy`.
Although I cannot reproduce a double free on my system, for some reason,
it should have actually resulted in a double free in all code paths.
When the cursor surface gets updated, it should be damaged.
This also bumps up `wl_compositor` to version 4 to be able to use
`wl_surface_damage_buffer`.
In `i3 4.16`, `i3-nagbar` introduces the flags `-B/--button-no-terminal`
to run the action directly instead of inside a terminal. This implements
the flags for swaynag for compatibility.
Since swaynag does not use an equivalent to `i3-sensible-terminal`, the
flags `-b/--button` only uses a terminal when the environment variable
`TERMINAL` is set, otherwise it acts the same as these new flags.
When destroying swaynag from within wl_display_dispatch, we cannot
disconnect the display as that will free the queue's event_list.
Free it after running the loop instead.
Fixes this use-after-free:
==7312==ERROR: AddressSanitizer: heap-use-after-free on address 0x612000000110 at pc 0x000000412a9f bp 0x7ffd4e811760 sp 0x7ffd4e811750
READ of size 8 at 0x612000000110 thread T0
#0 0x412a9e in wl_list_empty ../common/list.c:206
#1 0x7f5b58f0d42f in dispatch_queue src/wayland-client.c:1572
#2 0x7f5b58f0d42f in wl_display_dispatch_queue_pending src/wayland-client.c:1815
#3 0x40f465 in swaynag_run ../swaynag/swaynag.c:390
#4 0x407576 in main ../swaynag/main.c:123
#5 0x7f5b58bb9412 in __libc_start_main ../csu/libc-start.c:308
#6 0x404a3d in _start (/opt/wayland/bin/swaynag+0x404a3d)
0x612000000110 is located 208 bytes inside of 320-byte region [0x612000000040,0x612000000180)
freed by thread T0 here:
#0 0x7f5b594ab480 in free (/lib64/libasan.so.5+0xef480)
#1 0x40faff in swaynag_destroy ../swaynag/swaynag.c:454
#2 0x40cbb4 in layer_surface_closed ../swaynag/swaynag.c:82
#3 0x7f5b583e1acd in ffi_call_unix64 (/lib64/libffi.so.6+0x6acd)
previously allocated by thread T0 here:
#0 0x7f5b594aba50 in __interceptor_calloc (/lib64/libasan.so.5+0xefa50)
#1 0x7f5b58f0c902 in wl_display_connect_to_fd src/wayland-private.h:236
(you need a wayland compiled with asan, my wl_list hack, or running
with valgrind to see this trace)
It's better to use DT_RPATH dynamic section of the elf binary to store
the paths of libraries to load instead of overwriting LD_LIBRARY_PATH
for the whole environment, causing surprises. This solution is much more
transparent and perfectly suitable for running contained installations
of wayland/wlroots/sway.
The code unsetting the LD_LIBRARY_PATH/LD_PRELOAD was also deleted as
it's a placebo security at best - we should trust the execution path
that leads us to running sway, and it's way too late to care about those
variables since we already started executing our compositor, thus we
would be compromised anyway.
This does the following:
* Adds a baseline argument to get_text_size (the baseline is the
distance from the top of the texture to the baseline).
* Stores the baseline in the container when calculating the title
height.
* Takes the baseline into account when calculating the config's max font
height.
* When rendering, pads the textures according to the baseline so they
line up.
- Some platforms don't expose kill() unless _POSIX_C_SOURCE is defined.
- fork(), execl(), and setsid() need unistd.h on some platforms.
Basically, this fixes some platform-specific build errors.
Fixes segfauls for any case where swaynag->outputs was not inititalized
including -h/--help, -v/--version, and invalid arguments.
Sets sane defaults for colors not given. Any color not given will
fallback to the default color values for type error.
Adds support for a hidpi cursor
