#256 SIGBUS crash in libjxl during JXL decoding

[Rob Swindell]

Happens when running 2 SyncTERM instances on the same system/desktop (Ubuntu), both decoding JXL:

Bug Report: SIGBUS crash in libjxl during JXL decoding

Signal: SIGBUS (Bus error)
libjxl version: 0.7.0-10.2ubuntu6.1 (Ubuntu 24.04)
Image: 640x384 RGB 8-bit JXL (21KB file, appears valid)
File: ~/.cache/syncterm/cvs.synchro.net/d.jxl

Crashing thread backtrace:

  #0  0x00007a99ce766c83 in ?? () from libjxl.so
  #7  JxlResizableParallelRunner () from libjxl_threads.so
  #11 JxlDecoderProcessInput () from libjxl.so
  #12 read_jxl (fn="/home/rswindell/.cache/syncterm/cvs.synchro.net/d.jxl") at term.c:4311
  #13 draw_jxl_str_handler (str="SyncTERM:C;DrawJXL;DX=0;DY=0;d.jxl") at term.c:4503
  #14 apc_handler () at term.c:5014
  #15 do_ansi () at cterm.c:5464
  #16 cterm_write () at cterm.c:7055
  #17 doterm () at term.c:5982
  #18 main () at syncterm.c:2492

SIGBUS inside libjxl suggests either a corrupt/truncated mmap'd region or a libjxl bug in 0.7.0. The file on disk (21KB) appears intact after the crash.

---

★ Insight ─────────────────────────────────────

• SIGBUS vs SIGSEGV: SIGBUS typically means the CPU tried to access validly-mapped memory that has become inaccessible — often a memory-mapped file that was truncated or a shared memory segment that was removed. SIGSEGV would mean accessing an unmapped address entirely.
• libjxl 0.7.0 is quite old (current is 0.11+). This could be a known bug that's been fixed upstream. Worth checking if a newer libjxl resolves it, or if syncterm could gracefully handle decoder failures rather than crashing.
• The d.jxl file exists and is 21KB post-crash — so either the file was being written to while decoded (race condition), or there's a bug in libjxl's internal memory handling during parallel decoding (JxlResizableParallelRunner is in the stack).
  ─────────────────────────────────────────────────

[Rob Swindell]

This might be related, but I noticed that running 2 SyncTERM instances on the same Windows system/desktop, both instances decoding JXL, the images swap/flicker between the 2 instances (but no crash) - i.e. SyncTERM instance-1 shows the image for instance-2 and vice versa, very briefly, back and forth, continuously, until one of the instanaces stops decoding/displaying JXL.

[Stephen James Hurd]

I would absolutely suggest a newer libjxl. One thing to try would be deleting (or otherwise making sure dlopen() won't see libjxl_threads.so.

[Rob Swindell]

The swap/flicker of the image between 2 SyncTERM instances on Windows (no crash) was with v0.11.2, which I believe is the latest.

[Stephen James Hurd]

As for the Win32 issue, I assume it's because I'm putting the static library into a DLL, so the two instances end up unexpectedly sharing a heap.