cashing in vspipe - last working version was VapourBox-0.9.8-linux-x64

[dattrax]

All the version past VapourBox-0.9.8-linux-x64 cash at startup when loading a file

       PID: 11525 (vspipe-bin)
       UID: 1000 (jim)
       GID: 1000 (jim)
    Signal: 11 (SEGV)
 Timestamp: Mon 2026-09-21 18:57:53 BST (7s ago)

Command Line: /home/jim/.local/share/VapourBox/deps/linux-x64/vapoursynth/vspipe-bin -c y4m /tmp/557ec2a4-53e9-4411-9be6-043e779c219c_preview.vpy -
Executable: /home/jim/.local/share/VapourBox/deps/linux-x64/vapoursynth/vspipe-bin
Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-org.kde.konsole-3021.scope/tab(3088).scope
Unit: user@1000.service
User Unit: app-org.kde.konsole-3021.scope
Slice: user-1000.slice
Owner UID: 1000 (jim)
Boot ID: eaa19e7f0a40401aa4df66b36db973b0
Machine ID: 4f0769821fac49ebbc9f1420e07ae09e
Hostname: fedora
Storage: /var/lib/systemd/coredump/core.vspipe-bin.1000.eaa19e7f0a40401aa4df66b36db973b0.11525.1790013473000000.zst (present)
Size on Disk: 13.2M
Message: Process 11525 (vspipe-bin) of user 1000 dumped core.

            Module libzsmooth-haswell.so without build-id.
            Module libremovedirt.so without build-id.
            Module libz.so.1 from rpm zlib-ng-2.3.3-3.fc44.x86_64
            Module liblghost.so without build-id.
            Module libpython3.12.so.1.0 without build-id.
            Stack trace of thread 11550:
            #0  0x000055aa54f88670 n/a (n/a + 0x0)
            ELF object binary architecture: AMD x86-64

any ideas?

[StuartCameronCode]

Thanks for the crash report, the coredumpctl output is a good start.

I don't think this is the same problem as #92. That one is an illegal-instruction crash (SIGILL) on a CPU with no AVX2. Yours is a SIGSEGV on a worker thread, and the libzsmooth-haswell.so in the trace means the app detected AVX2 on your CPU. The trace has a single frame with no module or symbol, so it doesn't yet say which plugin is responsible. A few things would narrow it down.

1. Which version first crashes?

0.9.8 was the last one that worked. The next few releases (0.9.9, 0.9.10, 0.9.11) still used VapourSynth R73, and R78 arrived after them, so knowing which release first fails tells me a lot. If you can, try 0.9.9, then 0.9.10, 0.9.11 and 1.0.0, and tell me the first one that crashes. Note that each version downloads its own components into ~/.local/share/VapourBox/deps/, so move that folder aside (rename it) between tries.

2. Your CPU and SELinux state

lscpu | grep -E 'Model name|Flags'
getenforce

3. A backtrace with symbols

The one-line trace says the crash was at an address that isn't inside any library. Please run this on that core (you'll need sudo dnf install gdb if you don't have it) and paste the output:

eg.

coredumpctl gdb 11525

Then at the (gdb) prompt:

bt
info sharedlibrary
quit

If the PID has changed after another crash, use coredumpctl list vspipe-bin to find the newest one.

4. Test each plugin on its own

The attached script loads each bundled plugin in its own process and reports which ones crash. It also runs a core-only control, so it shows whether the problem is in one plugin or in VapourSynth itself. It takes a minute or two.

1. Unzip the attached vapourbox-plugin-test-v2.zip.
2. In a terminal:

cd <the unzipped folder>
bash probe-plugin-compat.sh

It finds your install at ~/.local/share/VapourBox/deps/linux-x64 by default. It writes vapourbox-plugin-compat-report.txt to ~/Desktop (or the current folder if you don't have one), so please attach that file or paste its contents.

Thanks. Whichever of these you can manage will help, and (4) is the quickest.

vapourbox-plugin-test-v2.zip