[bug] Dialog plugin causing Aborted (core dumped) on Linux when exiting the app

[SergeFan]

Describe the bug

As the title implied, using the tauri dialog plugin to open a file system dialog will cause Aborted (core dumped) when exiting the app. This seems to only happen to Linux.

Reproduction

This a code snip from my project, I have a button from frontend to trigger this command and it will open the file select dialog.

use directories::UserDirs;
use tauri_plugin_dialog::DialogExt;

#[tauri::command]
async fn select_path(app_handle: tauri::AppHandle) -> String {
    if let Some(user_dirs) = UserDirs::new() {
        let file_path = app_handle
            .dialog()
            .file()
            .set_directory(user_dirs.home_dir())
            .blocking_pick_folder();

...

#[cfg_attr(mobile, tauri::mobile_entry_point)]
pub fn run() {
    tauri::Builder::default()
        .plugin(tauri_plugin_dialog::init())
        .plugin(tauri_plugin_fs::init())
        .plugin(tauri_plugin_shell::init())
        .invoke_handler(tauri::generate_handler![
            ...
            select_path,
            ...
        ])
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

If I don't open the dialog and exit the app, it will close normally. But if I open the dialog (even just close the dialog and select nothing), it will give the Aborted (core dumped) error on exiting the app.

Aborted (core dumped)

Expected behavior

Opening file select dialog should not causing any core dumped error.

Full tauri info output

[✔] Environment
    - OS: Manjaro 24.2.1 x86_64 (X64)
    ✔ webkit2gtk-4.1: 2.46.4
    ✔ rsvg2: 2.59.2
    ✔ rustc: 1.83.0 (90b35a623 2024-11-26)
    ✔ cargo: 1.83.0 (5ffbef321 2024-10-29)
    ✔ rustup: 1.27.1 (2024-05-07)
    ✔ Rust toolchain: stable-x86_64-unknown-linux-gnu (environment override by RUSTUP_TOOLCHAIN)
    - node: 23.4.0
    - pnpm: 9.12.3
    - yarn: 1.22.22
    - npm: 10.9.2

[-] Packages
    - tauri 🦀: 2.1.1
    - tauri-build 🦀: 2.0.3
    - wry 🦀: 0.47.2
    - tao 🦀: 0.30.8
    - tauri-cli 🦀: 2.0.4

[-] Plugins
    - tauri-plugin-shell 🦀: 2.2.0
    - tauri-plugin-fs 🦀: 2.2.0
    - tauri-plugin-dialog 🦀: 2.2.0

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../dist
    - devUrl: http://localhost:1420/

Stack trace

No response

Additional context

No response

[TheComputerGuy96]

I get that behavior when making a dialog command function async (this also happens with rfd's GTK 3 backend which the Dialog plugin uses on Linux so maybe it should be reported upstream?)

But if I don't make it async then the whole program hangs (which could be the same issue as PolyMeilex/rfd#198)

[SergeFan]

@TheComputerGuy96

I have to use async since I'm using the blocking_pick_folder() and according to the doc this cannot be use on the main thread. As you mentioned the whole program hangs if I remove async.

And I test rfd's file pick dialog, both sync and async one with tokio, they work normally. But rfd with tauri, core dumped.

[TheComputerGuy96]

And I test rfd's file pick dialog, both sync and async one with tokio, they work normally.

I think that's because rfd uses the xdg-portal backend by default (it's in the default features) instead of gtk3 that tauri_plugin_dialog explicitly specifies in its rfd dependency

[SergeFan]

@TheComputerGuy96

I actually disabled default features in my cargo.toml.

rfd = {version = "0.15", default-features = false, features = ["gtk3"]}

And this is what I have tried, they all exits normally. (Even on Wayland session, I will metion at below.)

# main.rs

fn main() {
    # Async with std
    async_std::task::block_on(rfd::AsyncFileDialog::new().pick_folder());

    # Sync
    rfd::FileDialog::new().pick_folder();
}

#[tokio::main]
async fn main() {
    # Async with tokio
    rfd::AsyncFileDialog::new().pick_folder().await;
}

I think that's because rfd uses the xdg-portal backend by default (it's in the default features) instead of gtk3 that tauri_plugin_dialog explicitly specifies in its rfd dependency

Well I also tired X11 today and my app exited normally, so this error seems only happen to Wayland. Just asking, are you using Wayland session?

[FabianLars]

Your example code is not a good comparison imo. The 2 things that come to mind are that 1) Tauri also spawns a gtk event loop (which rfd does internally as well) and 2) Tauri exits via std::process::exit so rfd's Drop implementation does not run.

At first i thought 1) is the issue but after a bit of testing it seems like it's 2) and if rfd could expose a way to shutdown the thread at runtime we could fix this issue here.

I can't think of a good approach there though (in my testing i exposed a global static AtomicBool in rfd that i could change from iniside RunEvent::Exit) so maybe it makes more sense to test out the xdg portal implementation. It's file picker should work well enough for us, and imo it's fair to require zenity for the message dialogs. The less we directly depend on gtk the better imo. We're slowly moving away from it in tray-icon and if we end up completely replacing webkitgtk in favor of cef (instead of offering both) we could even get rid of gtk for the whole window.

[TheComputerGuy96]

if we end up completely replacing webkitgtk in favor of cef

I don't think this is a good idea right now though: chromiumembedded/cef#2804

[FabianLars]

I don't think this issue is that relevant for us. Currently the AppImage is our main distribution format and it also has to force x11 to prevent gtk crashes. Also, i'm so tired of complains about webkitgtk that i wouldn't mind just getting rid of all our own windowing and let cef do it itself 😂
Our cef integration will take a bit of time anyway so this doesn't really matter in this discussion so let's keep it out of here.