Linux (Arch) - SIGSEGV crashes on startup / thumbnail load (Wayland + niri, webkit2gtk 2.52.4, v0.7.0)

[nisidabay]

Environment

• OS: Arch Linux (rolling), kernel 7.0.12-arch1-1
• Desktop: niri (Wayland compositor)
• Package: omniget-bin v0.7.0-1 (from AUR, extracts GitHub release .rpm)
• WebKit: webkit2gtk-4.1 2.52.4-1
• GTK: gtk3 1:3.24.52-1
• Plugins: study 0.3.3, telegram 1.0.1, convert 1.0.2, courses 1.0.4

Symptoms

OmniGet crashes repeatedly with SIGSEGV, both during normal use and even when running CLI commands like omniget version. Multiple core dumps captured over several days (June 11–24).

Crash signatures (3 distinct sources)

1. WebKit + glycin (image decode) — most frequent
Appears when the app loads thumbnails/sprites for the study plugin. Logs fill with:

ERROR tauri::protocol::asset: asset protocol not configured to allow the path: /home/user/.local/share/wtf.tonho.omniget/plugins/study/data/courses/thumbnails/7367.jpg

Stack trace: webkit2gtk → libglycin-2.so.0 (image decode) → SIGSEGV
Note: the asset protocol scope in tauri.conf.json is "**", so this error should not appear — possible Tauri v2 bug or packaging issue.

2. libomniget_plugin_convert.so — tokio runtime crash
Thread crashes inside libomniget_plugin_convert.so tokio worker (parking_lot condvar / tokio scheduler).

3. libomniget_plugin_study.so — multiple worker threads dead
4+ study plugin tokio worker threads stuck in syscall(0, 0, ...) and then dead when the main thread aborts.

4. libsqlite3.so.0 — null dereference in telegram plugin
Thread 1450542 crashes at address 0x0000000000000000 (null dereference) inside sqlite3_bind called from libomniget_plugin_telegram.so (grammers_session set_dc_option).

Additional observations

• Plugin study auto-update from 0.3.3 → 0.3.4 fails: No artifact found for linux-x86_64 (0.3.4 release has no linux-x86_64 artifact, only macOS and Windows)
• Running GDK_BACKEND=x11 omniget partially mitigates but crashes still occur
• The AppImage from releases was not tested (using AUR package)

Full backtrace (most recent crash, thread that caused SIGSEGV)

Stack trace of thread 1450542:
#0  0x0000000000000000 n/a (n/a + 0x0)
#1  0x00007fbf414ac6dc n/a (libsqlite3.so.0 + 0x456dc)
#2  ... grammers_session set_dc_option → libomniget_plugin_telegram.so

Other threads in the same crash:

• 4+ study plugin threads: syscall → libomniget_plugin_study.so → libc
• 4+ convert plugin threads: parking_lot::condvar → tokio → libomniget_plugin_convert.so
• Glycin image decoder threads: libglycin-2.so.0
• WebKit/JavaScriptCore threads: WTF::RunLoop, WTF::ParkingLot

Expected behavior

OmniGet should not crash on launch or during normal use.

Additional context

The Flatpak installation mentioned in the README (flatpak install wtf.tonho.omniget) does not exist on Flathub — the app is not published there yet.

[tonhowtf]

Partial fix shipped in 35eaed5 (next release): (1) the asset-protocol denials are fixed — Tauri's scope didn't match paths containing dot components like ~/.local on Unix; (2) plugin loading is hardened (panics across FFI become load errors; the dylib is no longer dlclose'd while plugin threads may still run), which addresses the convert/study/telegram .so crashes. The remaining SIGSEGV inside webkit2gtk→libglycin image decoding is an upstream WebKit 2.52 bug on Arch — with (1) fixed the decoder pressure drops, but if it persists please report it to webkit2gtk / try downgrading, and send a fresh backtrace here. Leaving open to track.

[tonhowtf]

Update: we found the cause of the plugin crashes (the libomniget_plugin_convert.so / study / telegram ones — the WebKit thumbnail issue is separate, see below).

The app and its plugins are compiled Rust libraries, and Rust does not guarantee binary compatibility between compiler versions. Our release CI used an unpinned stable toolchain, so the app ended up built with one rustc version and the published plugins with another. The moment the app called into a plugin, the trait-object layout mismatched and the process died. We reproduced it in isolation: the old plugin binaries return corrupted data (an empty object where a populated array is guaranteed) when called from a differently-compiled host; rebuilt with a matching compiler they return correct data.

Fixed in the upcoming 0.7.2:

• the plugin ABI version was bumped and plugins now embed their compiler fingerprint, so an incompatible plugin is refused with a clear message instead of crashing the app;
• the toolchain is pinned in the app and in every plugin repo;
• all three plugins were rebuilt and republished (courses 1.0.5, telegram 1.0.2, convert 1.0.3).

Please update the app to 0.7.2 and your plugins when it lands, then let us know if the SIGSEGV at startup persists.

Separately, this release also fixes the asset protocol not configured to allow the path spam you saw: Tauri's scope defaults to requiring a literal leading dot on Unix, so ** never matched ~/.local/share/.... Thumbnails should load now. If a SIGSEGV inside webkit2gtk → libglycin still happens after that, that part is an upstream WebKit 2.52 bug rather than something we can fix in the app — a fresh backtrace would still be very welcome.