[bug] Creating two App instances causes tao panic on MacOS

[WSH032]

Describe the bug

My user reported this issue: pytauri/pytauri#99 (comment)

I suspect it's because pytauri instantiated two App instances:

1. https://github.com/WSH032/pytauri/blob/621053678f1de697a96ae0dd395e97542933d2bb/examples/nicegui-app/src/main.rs#L30-L37
2. https://github.com/WSH032/pytauri/blob/621053678f1de697a96ae0dd395e97542933d2bb/examples/nicegui-app/python/nicegui_app/__init__.py#L105-L124

Although we didn't actually use (App::run) the first App instance and just drop it after creation, using the second App instance caused tao to panic.

NOTE: This issue only occurs on MacOS, not on Linux or Windows.

Reproduction

use tauri::Manager as _;

pub fn run() -> Result<(), Box<dyn std::error::Error>> {
    let tauri_generate_context = || tauri::generate_context!();

    // Actually, we don't use this app, we just use it to get the resource directory
    let sample_app = tauri::Builder::default()
        .build(tauri_generate_context())
        .map_err(|err| format!("failed to build sample app: {err}"))?;
    let resource_dir = sample_app
        .path()
        .resource_dir()
        .map_err(|err| format!("failed to get resource dir: {err}"))?;
    println!("Resource dir: {:?}", resource_dir);
    drop(sample_app);

    tauri::Builder::default()
        .run(tauri_generate_context())
        .expect("error while running tauri application");

    Ok(())
}

Create the first App to get the resource directory, then drop it. Then create the second App instance and run it.

Expected behavior

Even if multiple App instances are created, as long as App::run is not called multiple times, it should not cause tao to panic.

Full tauri info output

ref: <https://github.com/pytauri/pytauri/issues/99#issue-2900095465>


[✔] Environment
    - OS: Mac OS 15.3.1 arm64 (X64)
    ✔ Xcode Command Line Tools: installed
    ✔ rustc: 1.83.0 (90b35a623 2024-11-26)
    ✔ cargo: 1.83.0 (5ffbef321 2024-10-29)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-aarch64-apple-darwin (default)
    - node: 22.14.0
    - pnpm: 9.10.0
    - yarn: 1.22.22
    - npm: 11.2.0
    - deno: deno 2.2.0

[-] Packages
    - tauri 🦀: 2.2.2
    - tauri-build 🦀: 2.0.5
    - wry 🦀: 0.48.1
    - tao 🦀: 0.31.1

[-] Plugins
    - tauri-plugin-notification 🦀: 2.2.0
    - tauri-plugin-opener 🦀: 2.2.2

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: http://localhost:8080/
    - devUrl: http://localhost:8080/

Stack trace

ref: <https://github.com/pytauri/pytauri/issues/99#issuecomment-2704872927>


LeMacMini@Mac-mini-von-The ~ % /Users/Studio-MacMini/Projects/pytauri/target/bundle-release/bundle/macos/nicegui-app.app/Contents/MacOS/nicegui-app ; exit;
INFO:     Started server process [24501]
INFO:     Waiting for application startup.
INFO:     Application startup complete.
INFO:     Uvicorn running on http://localhost:8080 (Press CTRL+C to quit)
thread 'main' panicked at /Users/Studio-MacMini/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tao-0.31.1/src/platform_impl/macos/app_state.rs:384:8:
The panic info must exist here. This failure indicates a developer error.
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at /Users/Studio-MacMini/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tao-0.31.1/src/platform_impl/macos/event_loop.rs:288:47:
called `Option::unwrap()` on a `None` value
thread 'main' panicked at core/src/panicking.rs:221:5:
panic in a function that cannot unwind
stack backtrace:
   0:        0x102c31220 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::h7adefaad4a31afc0
   1:        0x10240c740 - core::fmt::write::h381c0b0ce6ab972a
   2:        0x102c2e864 - std::io::Write::write_fmt::h75af97148630d8d3
   3:        0x102c310e0 - std::sys::backtrace::BacktraceLock::print::h8baf33e22611de71
   4:        0x102c31dd4 - std::panicking::default_hook::{{closure}}::h369c7295ef58c5b1
   5:        0x102c31c20 - std::panicking::default_hook::h50746358288a9d6a
   6:        0x102c3258c - std::panicking::rust_panic_with_hook::h7d795911432661cb
   7:        0x102c3221c - std::panicking::begin_panic_handler::{{closure}}::h36f15310ecbde379
   8:        0x102c316c8 - std::sys::backtrace::__rust_end_short_backtrace::heed121414170e0c7
   9:        0x102c31f08 - _rust_begin_unwind
  10:        0x102d7862c - core::panicking::panic_nounwind_fmt::h5d86a478a9d7437c
  11:        0x102d786a4 - core::panicking::panic_nounwind::he171ad52d328e60b
  12:        0x102d78790 - core::panicking::panic_cannot_unwind::h2dd8cd735765e065
  13:        0x102c59a9c - tao::platform_impl::platform::observer::control_flow_end_handler::h45862587692c4441
  14:        0x18e283be8 - <unknown>
  15:        0x18e283ad4 - <unknown>
  16:        0x18e2831a4 - <unknown>
  17:        0x18e282734 - <unknown>
  18:        0x1997f1530 - <unknown>
  19:        0x1997f7348 - <unknown>
  20:        0x1997f7508 - <unknown>
  21:        0x191dfa848 - <unknown>
  22:        0x192760c24 - <unknown>
  23:        0x191ded874 - <unknown>
  24:        0x102b13924 - tao::platform_impl::platform::event_loop::EventLoop<T>::run::hbf5095df774c0c0a
  25:        0x102ab05e4 - <tauri_runtime_wry::Wry<T> as tauri_runtime::Runtime<T>>::run::h12b05d0e07b7f8ab
  26:        0x102b002d8 - tauri::app::App<R>::run::h93e9a5a77327f20b
  27:        0x102b9c6c0 - pyo3::marker::Python::allow_threads::h033bc8032b134232
  28:        0x102b8f0b0 - pytauri_core::ext_mod_impl::App::__pymethod_run__::h1d939f75936f62fb
  29:        0x102b7bdc4 - pyo3::impl_::trampoline::trampoline::h5e92be9aed5d6bcf
  30:        0x102b8ec70 - pytauri_core::ext_mod_impl::<impl pyo3::impl_::pyclass::PyMethods<pytauri_core::ext_mod_impl::App> for pyo3::impl_::pyclass::PyClassImplCollector<pytauri_core::ext_mod_impl::App>>::py_methods::ITEMS::trampoline::h0e30b8dbd6cff7d0
  31:        0x104ab1c90 - _method_vectorcall_FASTCALL_KEYWORDS
  32:        0x104ae99a0 - __PyEval_EvalFrameDefault
  33:        0x104919454 - __PyFunction_Vectorcall
  34:        0x1048e33d0 - _call_function
  35:        0x104af5f74 - __PyEval_EvalFrameDefault
  36:        0x104980758 - __PyEval_Vector
  37:        0x1049ac5fc - _builtin_exec
  38:        0x104ac5458 - _cfunction_vectorcall_FASTCALL
  39:        0x1048e33d0 - _call_function
  40:        0x104af5f74 - __PyEval_EvalFrameDefault
  41:        0x104919454 - __PyFunction_Vectorcall
  42:        0x1048e33d0 - _call_function
  43:        0x104af5f74 - __PyEval_EvalFrameDefault
  44:        0x104919454 - __PyFunction_Vectorcall
  45:        0x1049fd074 - _pymain_run_module
  46:        0x1049fba28 - _Py_RunMain
  47:        0x102904c80 - pytauri::standalone::PythonInterpreter::run::h4c2b0d2e4a302456
  48:        0x1026309c4 - nicegui_app::main::hc1f54440ab6156e5
  49:        0x10267abb8 - std::sys::backtrace::__rust_begin_short_backtrace::h34bbf4bc237fc56c
  50:        0x1026426e8 - std::rt::lang_start::{{closure}}::h019793f643813e5c
  51:        0x102c2ad48 - std::rt::lang_start_internal::h77891a2543177e4b
  52:        0x102630ad0 - _main
thread caused non-unwinding panic. aborting.

Additional context

If we don't create sample_app, the above tao panic will not occur.

[WSH032]

CC @SeanPedersen, could you verify if this reproduces the issue?

[FabianLars]

not gonna lie, this sounds like a wontfix. The App struct was always something that should only exist once. On macOS it's a bit more strict because of the whole NSApplication shit and the obj-c interop in general.

If you really only need the resource dir then i'd either construct it manually or try to use https://docs.rs/tauri-utils/latest/tauri_utils/platform/fn.resource_dir.html directly. You can get PackageInfo via generate_context (which btw should also only be called once) and Env via Env::default()

[WSH032]

If this is by design, I think it should be explicitly documented, and an explicit panic or tauri::Result should be returned on the second call to Builder::build.

The current behavior on MacOS is inconsistent with Linux and Windows, which may confuse users.😨

Additionally, the tao backtrace is very obscure (it didn't help, I just happened to guess this by chance).

---

(which btw should also only be called once)

Just to make sure I didn't misunderstand you.🧐

Is this illegal:

let ctx0 = tauri::generate_context!();
let ctx1 = tauri::generate_context!();

Or is this illegal:

let ctx_builder = || tauri::generate_context!();
let ctx0 = ctx_builder();
let ctx1 = ctx_builder();

[FabianLars]

If this is by design, I think it should be explicitly documented, and an explicit panic or tauri::Result should be returned on the second call to Builder::build.

probably good idea

Is this illegal:

The first one is illegal and should, or used to, panic. The second one should be fine because it rust should make the macro run only once there. But with that syntax you may as well use a normal variable instead of a closure 🤷

[WSH032]

Thanks for the clarification.

probably good idea

If I have time, I will submit a PR to tauri so that I don't have to handle this issue downstream (pytauri) 😇.

But with that syntax you may as well use a normal variable instead of a closure

This is due to pytauri limitations. We use the factory pattern to allow users to write custom Rust code to adjust the Context instance they need based on Python input.

• https://github.com/pytauri/pytauri/blob/8e2455ad13ce15648aa1df1a880cea2caec43346/examples/tauri-app/src-tauri/src/lib.rs#L25-L26
• https://pytauri.github.io/pytauri/0.3/reference/py/pytauri/#pytauri.context_factory