Found this apparent race condition when making a script that had fzf call imv.
I can 99.9% of the time reproduce this issue with a command line like this:
./build/imv-wayland /dev/null & PID=$!; sleep 0.05; imv-msg $PID open ~/1.f-0.png
Backtrace from the coredump:
imv_window_push_event(window=0x0000000000000000, e=0x00007fef2f68e0b8) at wl_window.c:918:9 frame <a href="/~exec64/imv/1" title="~exec64/imv#1: segfault with latest wlroots/sway">#1</a>: 0x0000561698d0bae2 imv-wayland
command_callback(text="open /home/carlos/1.f-0.png",
data=0x00007fef354ca2a0) at imv.c:397:3
frame #2: 0x0000561698d0ed45
imv-waylandwait_for_commands(void_conn=0x00007fef30b932c0) at ipc.c:40:7 frame <a href="/~exec64/imv/3" title="~exec64/imv#3: Read image from stdin, not just file paths">#3</a>: 0x00007fef35669c7c ld-musl-x86_64.so.1
start(p=0x00007fef2f68e540) at
pthread_create.c:203:17
frame #4: 0x00007fef3566c53b ld-musl-x86_64.so.1`__clone + 47Backtraces from the other threads are here: https://paste.artixlinux.org/view/40384449
Adding a NULL check to imv.c:397 seems to dodge the issue (drops the message, but better than a crash, IMO).
I found a more proper fix to this here: https://lists.sr.ht/~exec64/imv-devel/patches/41893 Just mentioning this for anyone who stumbles upon this issue.