Segmentation fault if imv-msg is called too early in imv's initialization

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:

  • thread #1, name = 'imv-wayland', stop reason = signal SIGSEGV
    • frame #0: 0x0000561698d08680 imv-waylandimv_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-waylandcommand_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.1start(p=0x00007fef2f68e540) at pthread_create.c:203:17 frame #4: 0x00007fef3566c53b ld-musl-x86_64.so.1`__clone + 47

Backtraces 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).

Carlos Eduardo
Assigned to
1 year, 6 months ago
11 months ago
No labels applied.

blankie 11 months ago ยท edit

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.

Register here or Log in to comment, or comment via email.