dbt parse aborts with SIGABRT (stack overflow) in the load/parse phase on default thread stack

Help
1

Summary

Running dbt parse aborts with SIGABRT (Abort trap: 6) before producing any
error message. The crash report shows a stack overflow, not a panic — the
faulting thread bottoms out in the Rust stack-overflow signal handler while deep in
the project-load path (load_packages -> collect_packages -> load_inner -> loader::load).

Environment

  • dbt version: dbt-core 2.0.0-alpha.1 (built from source at branch main)
  • OS: macOS 15.7.4 (Build 24G517) / Darwin 24.6.0, arch: arm64 (Apple Silicon)
  • Toolchain: rustc 1.91.1 (ed61e7d7e 2025-11-07)
  • Install method: built from source (cargo test / cargo build)
  • Project: minimal — reproduces even on a hello-world project with no extra packages
    (the in-repo crates/dbt-sa-cli/tests/data/hello_world fixture).

Steps to reproduce

  1. dbt parse (or dbt parse --show progress) on a minimal project.
  2. Process exits with signal: 6, SIGABRT; stderr is empty (no panic message).

Evidence it is a stack overflow

The macOS crash report (~/Library/Logs/DiagnosticReports/...ips) shows:

  • EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE (guard-page hit)
  • faulting frames: std::sys::...::stack_overflow::signal_handler → abort
  • below that: dbt_loader::load_packages::collect_packages →
    load_inner → dbt_loader::loader::load (a deep async future chain wrapped in
    tracing::instrument).

Workaround that confirms the cause

Raising the thread stack to 8 MiB makes it pass:

RUST_MIN_STACK=8388608 dbt parse

(8 MiB matches what the production binary already configures internally for its
runtime threads.)

Question / ask

Is this a known issue with the default thread stack size in the parse/load path?
Should the engine raise the worker stack size (or shorten the async future chain in
the load path) so a minimal project does not overflow a 2 MiB stack out of the box?