Segmentation fault (core dumped) issue on build

[Parth2684]

I am making a file sharing app in tauri (ofc) and it works correctly in development mode but when i build it and open it the window opens and when i try to invoke any function it just freezes for sometime and then closes with the error Segmentation fault (core dumped)
App Repo: https://github.com/Parth2684/velocity .

My machine:
OS ➜ Arch Linux x86_64
Kernel ➜ Linux 6.19.14-arch1-1
WM ➜ niri 26.04
CPU ➜ AMD Ryzen 5 3500U (8) @ 2.10 GHz
GPU ➜ AMD Radeon Vega 8 Graphics [Integrated]
RAM ➜ 5.70GiB
SWAP ➜ 12.00 GiB
Storage ➜ 467.4 GiB

I first thought it was a arch related issue as there were some i found on internet and i tried to build it with ENV NO_STRIP=true and on docker(base image node:lts can be found in the repo root) but i still faced the same errors. (I have also tried cleaning cargo cache, cargo clean, deleteing target folder, etc)

Image when Application startes in dev mode and also in build mode

OTP seen in dev mode after i click on serve device

How to Recreate The Issue
But when i build the application(bun tauri build --no-bundle), start it using RUST_BACKTRACE=1 ./tartget/release/Velocity and tap on serve device it freezes and prints Segmentation fault (core dumped) or even if i do scan devices it does the same thing (in dev mode it currently prints to the terminal other events of mdns-sd or if a device is found then it JSON.stringifies the thing and shows on screen [Note: it does not freeze or exits])

I have some journalctl logs which I can't really understand:

[🡕] Process 57885 (velocity) of user 1000 dumped core.

                                               Stack trace of thread 57885:
                                               #0  0x000055ba40e92352 n/a (/usr/bin/velocity + 0x50d>
                                               #1  0x000055ba40d8ee6d n/a (/usr/bin/velocity + 0x409>
                                               #2  0x000055ba40d91ca0 n/a (/usr/bin/velocity + 0x40c>
                                               #3  0x000055ba40d93c32 n/a (/usr/bin/velocity + 0x40e>
                                               #4  0x000055ba40d5791f n/a (/usr/bin/velocity + 0x3d2>
                                               #5  0x000055ba40edfe97 n/a (/usr/bin/velocity + 0x55a>
                                               #6  0x00007fc031fafd59 n/a (libwebkit2gtk-4.1.so.0 + >
                                               #7  0x00007fc031f34193 n/a (libwebkit2gtk-4.1.so.0 + >
                                               #8  0x00007fc031ef5925 n/a (libwebkit2gtk-4.1.so.0 + >
                                               #9  0x00007fc031ef5748 n/a (libwebkit2gtk-4.1.so.0 + >
                                               #10 0x00007fc031879bfc n/a (libwebkit2gtk-4.1.so.0 + >
                                               #11 0x00007fc031deb112 n/a (libwebkit2gtk-4.1.so.0 + >
                                               #12 0x00007fc0318d8154 n/a (libwebkit2gtk-4.1.so.0 + >
                                               #13 0x00007fc031dddca9 n/a (libwebkit2gtk-4.1.so.0 + >
                                               #14 0x00007fc031de0782 n/a (libwebkit2gtk-4.1.so.0 + >
                                               #15 0x00007fc02f8bb61f n/a (libjavascriptcoregtk-4.1.>
                                               #16 0x00007fc02f8bb89f n/a (libjavascriptcoregtk-4.1.>
                                               #17 0x00007fc035da8f4d n/a (libglib-2.0.so.0 + 0x5ef4>
                                               #18 0x00007fc035daa607 n/a (libglib-2.0.so.0 + 0x6060>
                                               #19 0x00007fc035daa815 g_main_context_iteration (libg>
                                               #20 0x00007fc02fdead7f gtk_main_iteration_do (libgtk->
                                               #21 0x000055ba40d7e359 n/a (/usr/bin/velocity + 0x3f9>
                                               #22 0x000055ba40d7d567 n/a (/usr/bin/velocity + 0x3f8>
                                               #23 0x000055ba40d7d561 n/a (/usr/bin/velocity + 0x3f8>
                                               #24 0x000055ba40d7d447 n/a (/usr/bin/velocity + 0x3f8>
                                               #25 0x000055ba40d7d27f n/a (/usr/bin/velocity + 0x3f8>
                                               #26 0x000055ba40b2f1b1 n/a (/usr/bin/velocity + 0x1aa>
                                               #27 0x000055ba40b2e9ac n/a (/usr/bin/velocity + 0x1a9>
                                               #28 0x000055ba40b30759 n/a (/usr/bin/velocity + 0x1ab>
                                               #29 0x00007fc02d2276c1 n/a (libc.so.6 + 0x276c1)
                                               #30 0x00007fc02d2277f9 __libc_start_main (libc.so.6 +>
                                               #31 0x000055ba40b2e8e1 n/a (/usr/bin/velocity + 0x1a9>

                                               Stack trace of thread 57887:
                                               #0  0x00007fc02d31806d syscall (libc.so.6 + 0x11806d)
                                               #1  0x000055ba40bcd7b6 n/a (/usr/bin/velocity + 0x248>
                                               #2  0x000055ba40d216b8 n/a (/usr/bin/velocity + 0x39c>
                                               #3  0x000055ba40d20b4f n/a (/usr/bin/velocity + 0x39b>
                                               #4  0x000055ba40d27c6d n/a (/usr/bin/velocity + 0x3a2>
                                               #5  0x000055ba40d24206 n/a (/usr/bin/velocity + 0x39f>
                                               #6  0x000055ba40d2404d n/a (/usr/bin/velocity + 0x39f>
                                               #7  0x000055ba40cbd0c8 n/a (/usr/bin/velocity + 0x338>
                                               #8  0x00007fc02d29697a n/a (libc.so.6 + 0x9697a)

lines 1-46...skipping...
May 06 14:02:12 archlinux systemd-coredump[58256]: [🡕] Process 57885 (velocity) of user 1000 dumped core.

                                               Stack trace of thread 57885:
                                               #0  0x000055ba40e92352 n/a (/usr/bin/velocity + 0x50d352)
                                               #1  0x000055ba40d8ee6d n/a (/usr/bin/velocity + 0x409e6d)
                                               #2  0x000055ba40d91ca0 n/a (/usr/bin/velocity + 0x40cca0)
                                               #3  0x000055ba40d93c32 n/a (/usr/bin/velocity + 0x40ec32)
                                               #4  0x000055ba40d5791f n/a (/usr/bin/velocity + 0x3d291f)
                                               #5  0x000055ba40edfe97 n/a (/usr/bin/velocity + 0x55ae97)
                                               #6  0x00007fc031fafd59 n/a (libwebkit2gtk-4.1.so.0 + 0x1bafd59)
                                               #7  0x00007fc031f34193 n/a (libwebkit2gtk-4.1.so.0 + 0x1b34193)
                                               #8  0x00007fc031ef5925 n/a (libwebkit2gtk-4.1.so.0 + 0x1af5925)
                                               #9  0x00007fc031ef5748 n/a (libwebkit2gtk-4.1.so.0 + 0x1af5748)
                                               #10 0x00007fc031879bfc n/a (libwebkit2gtk-4.1.so.0 + 0x1479bfc)
                                               #11 0x00007fc031deb112 n/a (libwebkit2gtk-4.1.so.0 + 0x19eb112)
                                               #12 0x00007fc0318d8154 n/a (libwebkit2gtk-4.1.so.0 + 0x14d8154)
                                               #13 0x00007fc031dddca9 n/a (libwebkit2gtk-4.1.so.0 + 0x19ddca9)
                                               #14 0x00007fc031de0782 n/a (libwebkit2gtk-4.1.so.0 + 0x19e0782)
                                               #15 0x00007fc02f8bb61f n/a (libjavascriptcoregtk-4.1.so.0 + 0x22bb61f)
                                               #16 0x00007fc02f8bb89f n/a (libjavascriptcoregtk-4.1.so.0 + 0x22bb89f)
                                               #17 0x00007fc035da8f4d n/a (libglib-2.0.so.0 + 0x5ef4d)
                                               #18 0x00007fc035daa607 n/a (libglib-2.0.so.0 + 0x60607)
                                               #19 0x00007fc035daa815 g_main_context_iteration (libglib-2.0.so.0 + 0x60815)
                                               #20 0x00007fc02fdead7f gtk_main_iteration_do (libgtk-3.so.0 + 0x1ead7f)
                                               #21 0x000055ba40d7e359 n/a (/usr/bin/velocity + 0x3f9359)
                                               #22 0x000055ba40d7d567 n/a (/usr/bin/velocity + 0x3f8567)
                                               #23 0x000055ba40d7d561 n/a (/usr/bin/velocity + 0x3f8561)
                                               #24 0x000055ba40d7d447 n/a (/usr/bin/velocity + 0x3f8447)
                                               #25 0x000055ba40d7d27f n/a (/usr/bin/velocity + 0x3f827f)
                                               #26 0x000055ba40b2f1b1 n/a (/usr/bin/velocity + 0x1aa1b1)
                                               #27 0x000055ba40b2e9ac n/a (/usr/bin/velocity + 0x1a99ac)
                                               #28 0x000055ba40b30759 n/a (/usr/bin/velocity + 0x1ab759)
                                               #29 0x00007fc02d2276c1 n/a (libc.so.6 + 0x276c1)
                                               #30 0x00007fc02d2277f9 __libc_start_main (libc.so.6 + 0x277f9)
                                               #31 0x000055ba40b2e8e1 n/a (/usr/bin/velocity + 0x1a98e1)

                                               Stack trace of thread 57887:
                                               #0  0x00007fc02d31806d syscall (libc.so.6 + 0x11806d)
                                               #1  0x000055ba40bcd7b6 n/a (/usr/bin/velocity + 0x2487b6)
                                               #2  0x000055ba40d216b8 n/a (/usr/bin/velocity + 0x39c6b8)
                                               #3  0x000055ba40d20b4f n/a (/usr/bin/velocity + 0x39bb4f)
                                               #4  0x000055ba40d27c6d n/a (/usr/bin/velocity + 0x3a2c6d)
                                               #5  0x000055ba40d24206 n/a (/usr/bin/velocity + 0x39f206)
                                               #6  0x000055ba40d2404d n/a (/usr/bin/velocity + 0x39f04d)
                                               #7  0x000055ba40cbd0c8 n/a (/usr/bin/velocity + 0x3380c8)
                                               #8  0x00007fc02d29697a n/a (libc.so.6 + 0x9697a)
                                               #9  0x00007fc02d31a2bc n/a (libc.so.6 + 0x11a2bc)

Code for serving device can be found in the repo at : velocity/src-tauri/src/commands/connect_server.rs.rs and velocity/src-tauri/src/commands/helpers/find_device_sender.rs
Code for searching devices can be found in the repo at: velocity/src-tauri/src/commands/scan_devices.rs and velocity/src-tauri/src/commands/helpers/find_device_receiver.rs

Also I tried to build on android(bun tauri android build and signing the app later before installation) and the same thing happens on my phone (OnePlus 6T) the app opens but crashes as soon as I try to invoke any function by tapping any button

Happy to know if you too faced this issue and how'd you solve it or is it just me issue or a tauri issue
(also sorry for such a bad frontend it is not yet finished)

[mg1986jp]

The stack trace points to a crash inside libwebkit2gtk-4.1.so triggered during JavaScript execution — specifically through the IPC bridge (the #[tauri::command] invoke path). The fact that it works in dev but crashes in release builds suggests an optimization-related issue.

A few things to try:

1. Build with debug symbols to get a readable stack trace:

# Cargo.toml
[profile.release]
debug = true
strip = false

Then run with RUST_BACKTRACE=full to get function names instead of hex offsets.

2. Check if it's a threading issue — mdns-sd spawns its own threads for mDNS discovery. If those threads try to interact with the Tauri IPC or webview from a non-main thread, you'll get undefined behavior that manifests as a segfault. In your connect_server.rs and scan_devices.rs, make sure you're not calling app_handle.emit() or similar from the mDNS callback thread without using tauri::async_runtime::spawn or a channel to marshal back to the async runtime.

3. The Android crash confirms it's not platform-specific — which points to your Rust code rather than a webkit/GTK issue. Look at how you're passing data from the mDNS discovery callbacks back to the frontend. If you're holding a reference to something that gets dropped, the serialization in the IPC layer will segfault.

4. Try isolating the problem:

# Build without mDNS features first
# Comment out the scan/serve commands and see if the app at least stays alive

If the app works fine in release without the mDNS commands, the issue is in how mdns-sd interacts with the Tauri runtime in release mode (optimizations can reorder operations that happen to work in debug).

Can you share the relevant command signatures from connect_server.rs? Specifically, are you using State<> or AppHandle in the command parameters?

[lizuju]

I looked through the repo. I would not start with WebKit here; there are a couple of concrete Rust-side issues that can explain the "works in dev, core dumps in release" behavior.

The biggest one is your release profile:

[profile.release]
panic = "abort"
strip = true

With panic = "abort", any unwrap() / expect() inside an invoked command can terminate the whole process instead of unwinding. In a desktop app that often looks like a segfault/core dump.

There are several panics reachable from the buttons you mentioned, for example:

tokio::spawn(async move { ... }) // in a sync Tauri command

inside serve_and_connect_quic, plus expect() / unwrap() around open_bi, TcpListener::bind, mdns.register, mdns.shutdown, etc.

I would first change the background tasks to use Tauri's runtime instead of plain tokio::spawn from a sync command:

tauri::async_runtime::spawn(async move {
    while let Some(incoming_conn) = endpoint.accept().await {
        // ...
    }
});

Then remove the panicking calls on the invoke path and return Result<_, String> instead. While debugging, also temporarily use:

[profile.release]
debug = true
strip = false
panic = "unwind"

so you get the actual panic message instead of an abort.

There is a second issue in scan(): it calls recv_search() directly, and recv_search() loops on recv.recv(). That means the command does not return while scanning is on. Since the frontend does await scan(Discovery.On), the invoke stays pending forever. Also, inside recv_search() you hold the Mutex<AppState> while waiting for mDNS events and emitting to the frontend. That can block other commands that need the same state.

I would make scan(On) start a background task and return immediately:

#[tauri::command]
pub fn scan(app: tauri::AppHandle, discovery: Discovery) -> Result<(), String> {
    {
        let state = app.state::<Mutex<AppState>>();
        state.lock().map_err(|_| "state lock failed")?.discovery = discovery;
    }

    if matches!(discovery, Discovery::On) {
        let app = app.clone();
        tauri::async_runtime::spawn_blocking(move || {
            if let Err(err) = find_device_receiver::recv_search(&app) {
                eprintln!("scan failed: {err}");
            }
        });
    }

    Ok(())
}

and inside recv_search(), do not keep the mutex guard alive while waiting on recv.recv().

So the short checklist I would try:

1. Replace tokio::spawn in commands with tauri::async_runtime::spawn / spawn_blocking.
2. Make scan(On) return immediately; run the mDNS loop in the background.
3. Remove unwrap() / expect() from all command paths.
4. Disable panic = "abort" until the crash is fixed.

My guess is the release build is not exposing a WebKit bug; it is aborting on a Rust panic, and the release profile makes that look like a native crash.