Stack Overflow on 'goose configure'

[d432456463]

Running the goose configure command on a fresh build from source on Windows consistently results in a thread 'main' has overflowed its stack crash. This issue occurs before any output is printed to the console and appears to be a fundamental bug in the command's startup or provider initialization sequence, as it persists even when all providers are disabled.

Environment

• goose-cli Versions Tested: v1.15.0 (latest master), v1.14.0
• Operating System: Windows

Steps to Reproduce

1. Get Source Code: Download the source code for goose-cli (e.g., v1.14.0 from the releases page).
2. Setup Windows Build Environment:
   • Install Rust via rustup.
   • Install Visual Studio Build Tools with the "Desktop development with C++" workload.
3. Apply Build Fixes: Two workarounds are required to get the project to compile on Windows:
   • Fix crunchy dependency: The git dependency for crunchy fails to fetch. It must be downloaded manually and patched in Cargo.toml to use a local path:

1 # In Cargo.toml 2 [patch.crates-io] 3 # crunchy = { git = "...", branch = "..." } # This fails 4 crunchy = { path = "../path/to/local/crunchy/source" } # This works * Fix Linker Error: The build fails with LNK2019: unresolved external symbol SystemFunction036. This is resolved by creating a .cargo/config.toml file with the following content: 1 [target.x86_64-pc-windows-msvc] 2 rustflags = ["-C", "link-arg=advapi32.lib"] 4. Build the CLI: Run cargo build -p goose-cli. The build should complete successfully. 5. Run the command: Execute the built binary: 1 .\target\debug\goose.exe configure

Expected Behavior

The goose configure command should start and display a list of available providers for configuration.

Actual Behavior

The command immediately crashes with the following message, and no other output is produced: 1 thread 'main' has overflowed its stack

Debugging Steps Taken / Additional Context

This appears to be a deep, blocking bug in the application's startup logic.

1. No Stack Trace: Setting the RUST_BACKTRACE=1 environment variable does not produce a stack trace, making direct debugging very difficult.
2. Provider Isolation Test: The most critical finding is that this crash occurs even when all providers are commented out from the init_registry function in crates/goose/src/providers/factory.rs. This strongly indicates the bug is not in any specific provider's code but in the CLI's core logic that runs before or during provider registration for the configure command.
3. Initialization Path: The crash seems to happen during the initialization of any command that needs to create a provider instance. A test with a new, minimal custom command that simply tried to create one provider instance also resulted in the same stack overflow.

Given these findings, it seems there is a recursive loop or a massive stack allocation bug in the goose-cli startup sequence on Windows when running commands that interact with the provider framework.

[DOsinga]

thanks for the deepdive. I know @jamadeo looked into getting goose to compile on windows. it is strange though because I think our distribution doesn't do this, neither does this happen on other OS's. can you share a branch with the modifcations you made to make it compile?

[d432456463]

gemini_oauth.txt oauth_client.txt Here are the two key files as requested: the new gemini_oauth.rs provider and the modified oauth_client.rs.

[taniandjerry]

Thank you for sharing them! How can we followup from here, @block/goose-core-maintainers ?