panic: switch on corrupt value in string.zig during long-running session on Windows

[jiaoshi888]

Description

Bun crashes with panic(main thread): switch on corrupt value after a long-running session on Windows. The crash appears to be a memory management issue in string object handling during event loop cleanup.

Crash Report

Bun crash report URL: https://bun.report/1.3.10/e_21979c94mgkgEuhogD09gkQ4p4vbq705Vwws1U23wN284hUm5nlOiq4kOwkzjwDCYKERNEL32.DLLo35FCSntdll.dllipmTA0eNorLs8sSc5QyM9TSM4vKiotKFEoS8wpTQUAa8EI/A

Environment

• Bun Version: 1.3.10-canary.63 (1979c945)
• Platform: Windows x64 (baseline)
• OS: Windows 10 (win10_ni)
• CPU: sse42 avx avx2

Runtime Statistics at Crash

Metric	Value
Elapsed time	1,186,847ms (~19.7 minutes)
User CPU time	38,625ms
Sys CPU time	3,968ms
RSS Memory	0.86 GB
Peak Memory	0.93 GB
Commit Memory	1.21 GB
Page Faults	935,139
Machine RAM	68.53 GB

Stack Trace (from crash report)

The failure chain:

1. string.zig:885 — dereference operation (root cause)
2. Strong.zig:58 — during deinitialization
3. event_loop.zig:501 — event loop cleanup
4. JavaScript VM binding layer — surface crash point

Features Enabled at Crash

Bun.stderr, Bun.stdin, Bun.stdout, abort_signal, fetch, http_client_proxy, jsc, spawn, standalone_executable, process_dlopen, yaml_parse

Builtins Loaded

bun:main, node:assert, node:async_hooks, node:buffer, node:child_process, node:constants, node:crypto, node:events, node:fs, node:fs/promises, node:http, node:https, node:module, node:net, node:os, node:path, node:path/posix, node:path/win32, node:perf_hooks, node:process, node:stream, node:timers/promises, node:tls, node:tty, node:url, node:util, node:zlib, node:worker_threads, undici, ws, node:http2

Steps to Reproduce

1. Run a Bun-based application (Claude Code CLI) on Windows
2. Keep it running for an extended period (15–20+ minutes)
3. During this time, memory usage grows to ~0.86 GB RSS
4. Crash occurs with panic(main thread): switch on corrupt value

Expected Behavior

Bun should handle long-running sessions without crashing due to internal string object corruption.

Actual Behavior

panic(main thread): switch on corrupt value
oh no: Bun has crashed. This indicates a bug in Bun, not your code.

Additional Context

• This appears to be reproducible under high memory usage (>0.8 GB RSS) after extended runtime
• The crash is consistent with memory corruption in string handling during event loop lifecycle management
• Application is Claude Code CLI (claude.exe) which is distributed as a Bun standalone executable

[github-actions]

Found 3 possible duplicate issues:

1. Panic when returning collections with three or more arrays or objects inside macros #22656
2. Segmentation fault after long-running session (v1.3.9-canary.51) #26984
3. Segfault after ~70h uptime on Windows x64 (canary 1.3.9-canary.62) #27097

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[SPetersonNICE]

I just had a very similar crash and your URL crash tool uploaded a report (i think), but here's some details.
Apologies if this is in the wrong place or not helpful, but I'll give it a shot.

I was running ClaudeCode and reproduced this crash twice back to back. The second time I asked to resume the previous process and the crash happened in under 2 minutes. Claude appears to have been re-attempting the same actions on the same files when it crashed again.

• 128GB of RAM, 10% in-use.
• Windows 11 Pro for Workstations, 24H2

Can't give you my project but the ClaudeCode prompt was like this (within a small-medium sized C++ sandbox project)

docs/future_specs.md includes a high-level backlog of todo tasks to be worked on, with only high-level pre-planning done.

  Review Spec 1, and have the planner create a detailed implementation plan, explore the code if necessary.
  Review the planning, thinking about what needs to be done and the most straightforward approach.
  Have a worker implement the changes and wait for feedback.
  Have a reviewer review the line item changes in immediate context and give feedback or acceptance, to the worker.
  Once the first reviewer accepts, have a second reviewer review the changes in each file offering feedback or acceptance to
  the worker.
  For larger tasks, have a third reviewer look at the big picture to ensure things are clear and complete and inline with
  documented practices and the original plan, ensuring the program builds and solutions execute producing expected output,
  before offering a feedback summary of final reviews
  As orchestrator, give your own final summary when the task is complete.

  Start with Spec 1 and stop when that is completed.
  If things can be broken down or paralleized by multiple workers you may do that.

and later

 ClaudeCode crashed before the last operation completed. Please determine where you left off and resume.

❯ ClaudeCode crashed before the last operation completed. Please determine where you left off and resume.

● I can see we were in the middle of the SPEC-1 review process. The second reviewer identified issues with exercise3.cpp and
  solution3.cpp that need to be fixed. Let me resume by having the worker address those issues.

● Task(Fix exercise3 and solution3 issues)
  ⎿  Waiting…/c/source/ProjectFoo && git status --short courses/module1/exercises/exercise2.cpp

     Waiting…/c/source/ProjectFoo/build && cmake --build . --config Release --target m1_exercise2 --target m1_solution2)
     +35 more tool uses (ctrl+o to expand)
     ctrl+b to run in background

✻ Razzle-dazzling… (2m 15s · ↓ 2.9k tokens)

───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
❯ 
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
  esc to interrupt
============================================================
Bun Canary v1.3.10-canary.63 (1979c945) Windows x64 (baseline)
Windows v.win11_dt
CPU: sse42 avx avx2 avx512
Args: "C:\Users\<username>\.local\bin\claude.exe"
Features: Bun.stderr(2) Bun.stdin(2) Bun.stdout(2) abort_signal(4) fetch(43) jsc spawn(57) standalone_executable process_dlopen
Builtins: "bun:main" "node:assert" "node:async_hooks" "node:buffer" "node:child_process" "node:constants" "node:crypto" "node:events" "node:fs" "node:fs/promises" "node:http" "node:https" "node:module" "node:net" "node:os" "node:path" "node:path/posix" "node:path/win32" "node:perf_hooks" "node:process" "node:stream" "node:timers/promises" "node:tls" "node:tty" "node:url" "node:util" "node:zlib" "node:worker_threads" "undici" "ws" "node:http2"
Elapsed: 490056ms | User: 21000ms | Sys: 7140ms
RSS: 0.67GB | Peak: 0.91GB | Commit: 0.99GB | Faults: 864779 | Machine: 0.14TB

panic(main thread): switch on corrupt value
oh no: Bun has crashed. This indicates a bug in Bun, not your code.

To send a redacted crash report to Bun's team,
please file a GitHub issue using the link below:

 https://bun.report/1.3.10/e_21979c94mgEuhogC09gkQ4p4vbq705Vwws1U23wN284hUm5nlOiq4kOwkzjwDCYKERNEL32.DLLut0LCSntdll.dll4gijBA0eNorLs8sSc5QyM9TSM4vKiotKFEoS8wpTQUAa8EI/A

[dylan-conway]

Fixed in #27324, and is included in claude code v2.1.53