-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

I can repro this crash on Hyprland pretty consistently, so it must be a wlroots issue. I was able to trace it back to this commit: https://gitlab.freedesktop.org/wlroots/wlroots/-/commit/18595000f3a21502fd60bf213122859cc348f9af Reverting it makes the crash go away, but is obviously not a solution.

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQR7rht6B3uFIzc6C2ntNaasZaBraQUCZfWIBwAKCRDtNaasZaBr aVcuAP4w8FGG/ywMiE2Y7qK8Ch7Kba93XRmVmX2D3zbQ6abiHAEAi0lqJ1JhKBPx RYL70UsS4GdtwmsLWuzTDziDRAl36Qg= =MWaF -----END PGP SIGNATURE-----

The same problem occurs under the following settings:

• Arch Linux
• imv: 4.5.0
• Hyprland: >= 0.37.0
• monitor scaling: >1.0

The output_data->pending_scale = 1 hack mentioned in #20 seems to be fine and works perfectly for me, no matter how the monitor scaling changes.

I see a very similar situation:

wl_surface@11: error 2: Buffer size (2074x811) is not divisible by scale (2)

However, for me imv does not exit. The window closes but imv-wayland continues running consuming 100% CPU indefinitely.

• Alpine Linux Edge
• imv-4.5.0-r0 x86_64
• sway version 1.10-dev-646019cad (Apr 30 2024, branch 'master')
• monitor scale 1.6, and can repro on another host with scale 1.5

The issue happens when imv loses focus, so steps to reproduce are:

• Open two imv instances.
• Switch focus back and forth.

I generated a stacktrace:

wl_surface@11: error 2: Buffer size (2074x811) is not divisible by scale (2)
^C
Thread 1 "imv-wayland" received signal SIGINT, Interrupt.
__cp_end () at src/thread/x86_64/syscall_cp.s:29
warning: 29	src/thread/x86_64/syscall_cp.s: No such file or directory
(gdb) bt
#0  __cp_end () at src/thread/x86_64/syscall_cp.s:29
<a href="/~exec64/imv/1" title="~exec64/imv#1: segfault with latest wlroots/sway">#1</a>  0x00007ffff7fb7617 in __syscall_cp_c
    (nr=0, u=<optimized out>, v=<optimized out>, w=<optimized out>, x=<optimized out>, y=<optimized out>, z=0)
    at src/thread/pthread_cancel.c:33
<a href="/~exec64/imv/2" title="~exec64/imv#2: open command cannot handle spaces">#2</a>  0x00007ffff7fbe5da in read (fd=<optimized out>, buf=buf@entry=0x7fffffffd2d0, count=count@entry=40)
    at src/unistd/read.c:6
<a href="/~exec64/imv/3" title="~exec64/imv#3: Read image from stdin, not just file paths">#3</a>  0x000055555555d8a5 in read (__n=40, __s=0x7fffffffd2d0, __f=<optimized out>)
    at /usr/include/fortify/unistd.h:118
<a href="/~exec64/imv/4" title="~exec64/imv#4: &#39;center&#39; not working with -c">#4</a>  imv_window_pump_events
    (window=0x7ffff5f4c760, handler=handler@entry=0x555555561130 <event_handler>, data=data@entry=0x7ffff66c7910)
    at ../src/wl_window.c:931
<a href="/~exec64/imv/5" title="~exec64/imv#5: config is dependent on declaration order">#5</a>  0x0000555555563126 in imv_run (imv=imv@entry=0x7ffff66c7910) at ../src/imv.c:1277
<a href="/~exec64/imv/6" title="~exec64/imv#6: rename current image">#6</a>  0x000055555555c0fb in main (argc=2, argv=0x7fffffffdc38) at ../src/main.c:64

I have this patch applied, so line numbers for imv.c might not match entirely. However, it seems that the main loop keeps running even after the compositor returns an error.

Apparently, imv_window_pump_events ignores read errors. If the error is EAGAIN or EWOULDBLOCK, then this behaviour is fine (e.g.: no more events for now), but I suspect that in this case the error is the pipe having been closed.