tauri-apps/tauri · critical

unable to create thread with 8MiB stack

Error message

unable to create thread with 8MiB stack

What it means

Runtime panic in code emitted by tauri-codegen (added so rust-analyzer stays fast): Context creation runs on a dedicated thread built with thread::Builder::stack_size(8 * 1024 * 1024).spawn(...), and .expect("unable to create thread with 8MiB stack") fires when the OS refuses to spawn that thread — normally memory limits (RLIMIT_AS, cgroups) or thread/process limits — killing the app at startup.

Source

Thrown at crates/tauri-codegen/src/context.rs:479

    );

    #with_tray_icon_code
    #maybe_config_parent_setter

    context
  });

  // Wrapping in a function to make rust analyzer faster,
  // see https://github.com/tauri-apps/tauri/pull/14457
  // We take the assets as an argument so when the caller provides custom `assets` the closure
  // does not capture from the caller's scope ("can't capture dynamic environment in a fn item").
  let output = quote!({
    fn inner<R: #root::Runtime, A: #root::Assets<R> + 'static>(assets: A) -> #root::Context<R> {
      let thread = ::std::thread::Builder::new()
        .name(String::from("generated tauri context creation"))
        .stack_size(8 * 1024 * 1024)
        .spawn(move || #context)
        .expect("unable to create thread with 8MiB stack");

      match thread.join() {
        Ok(context) => context,
        Err(_) => {
          eprintln!("the generated Tauri `Context` panicked during creation");
          ::std::process::exit(101);
        }
      }
    }
    inner(#assets)
  });

  Ok(output)
}

fn find_icon(
  config: &Config,
  config_parent: &Path,

View on GitHub (pinned to 52e4b6e71d)

Solutions

1. Raise or remove the virtual-memory limit: increase `ulimit -v` and the container/systemd memory cap
2. Check thread/process ceilings: `ulimit -u`, systemd TasksMax, cgroup pids.max — leave headroom for one more thread
3. Reduce threads spawned before main (background pools, agents) so the context thread can be created
4. Update to the latest Tauri patch release and, if limits were already adequate, report the environment details upstream

Example fix

# before: docker run --memory=32m myapp → panics at startup
# after: give the app room for the 8 MiB context thread
docker run --memory=512m myapp

# verify the deployment environment can spawn an 8 MiB-stack thread
ulimit -v unlimited 2>/dev/null || echo "WARNING: RLIMIT_AS set"
python3 -c "import threading;threading.stack_size(8*1024*1024);t=threading.Thread(target=lambda:None);t.start();t.join();print('8MiB thread OK')"

When it happens

Trigger: Launching the app where virtual memory is capped below the 8 MiB stack plus working set (`ulimit -v`), a container cgroup memory limit hit during startup, or an exhausted thread/process limit (RLIMIT_NPROC, systemd TasksMax) in a restricted sandbox.

Common situations: Minimal Docker containers with tight --memory or ulimit -v settings; systemd units with MemoryLimit/TasksMax set too low; heavily threaded apps (runtime pools, telemetry SDKs) hitting limits before Context creation.

Related errors

• unable to generate cryptographically secure keys for Tauri \
• asset protocol path "{path}" is not valid: {e}
• File does not exist at path: {path}
• default_runtime only supports `struct`, `enum`, `type`, or `
• Could not read binary file.

AI-assisted analysis of tauri-apps/tauri@52e4b6e71d (2026-08-20). Data as JSON: /api/errors/b1e1747a44a4b87f. Report an issue: GitHub.