Description
OpenCode crashed with a Segmentation fault at address 0xFFFFFFFFFFFFFFFF in the embedded Bun v1.3.5 runtime on Windows x64. The crash occurred during an active session where the 01-Planner agent was executing a command.
The panic reported:
panic(thread 240212): Segmentation fault at address 0xFFFFFFFFFFFFFFFF
oh no: Bun has crashed. This indicates a bug in Bun, not your code.
panic: Segmentation fault at address 0xFFFFFFFFFFFFFFFF
panicked during a panic. Aborting.
The process had been running for 981385ms (~16 minutes) before the crash.
Environment
- Platform: Windows 11 (win32)
- OpenCode Version: 1.1.45
- Bun Version: v1.3.5 (1e86cebd)
- Agent: 01-Planner (gemini-3-flash-preview)
- Memory: RSS: 0.87GB | Peak: 0.90GB | Commit: 1.76GB
- CPU: sse42 avx avx2
Context / Steps to Reproduce
The crash occurred while the Planner was handling a request to test a model connection:
opencode run -m moonshot/kimi-k2.5 "Hello, are you Kimi 2.5?"
Logs show that the process was heavily engaged in permission evaluation and bus messaging immediately before the crash. There were signs of a potential "silent" hang or loop (logs stopped recording for a long period while the elapsed time continued to climb to 981s).
Correlation with Existing Issues
This appears related to #8785 and #8736, but specifically targets a crash during high-intensity Planner/subagent coordination on Windows, resulting in the 0xFFFFFFFFFFFFFFFF address and a "panic during a panic" state.
Artifacts
Description
OpenCode crashed with a
Segmentation fault at address 0xFFFFFFFFFFFFFFFFin the embedded Bun v1.3.5 runtime on Windows x64. The crash occurred during an active session where the 01-Planner agent was executing a command.The panic reported:
The process had been running for 981385ms (~16 minutes) before the crash.
Environment
Context / Steps to Reproduce
The crash occurred while the Planner was handling a request to test a model connection:
opencode run -m moonshot/kimi-k2.5 "Hello, are you Kimi 2.5?"Logs show that the process was heavily engaged in permission evaluation and bus messaging immediately before the crash. There were signs of a potential "silent" hang or loop (logs stopped recording for a long period while the elapsed time continued to climb to 981s).
Correlation with Existing Issues
This appears related to #8785 and #8736, but specifically targets a crash during high-intensity Planner/subagent coordination on Windows, resulting in the
0xFFFFFFFFFFFFFFFFaddress and a "panic during a panic" state.Artifacts