Segmentation fault

[oleg-koval]

What version of Bun is running?

v1.3.10

What platform is your computer?

Darwin 25.1.0 arm64 arm

What steps can reproduce the bug?

Happend during fixing atuing installation using claude agent

What is the expected behavior?

No response

What do you see instead?

Bun v1.3.10 (89a8aa9b) macOS Silicon
macOS v26.1
CPU: fp aes crc32 atomics
Args: "claude"
Features: Bun.stderr(2) Bun.stdin(2) Bun.stdout(2) WebSocket abort_signal(100) fetch(1458) http_server jsc spawn(251) standalone_executable process_dlopen yaml_parse(167)
Builtins: "bun:main" "node:assert" "node:async_hooks" "node:buffer" "node:child_process" "node:constants" "node:crypto" "node:dns" "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"
Elapsed: 100877475ms | User: 854350ms | Sys: 162433ms
RSS: 0.26GB | Peak: 0.44GB | Commit: 0.02ZB | Faults: 1433 | Machine: 38.65GB

redacted crash report

Additional information

No response

[robobun]

Unfortunately, I was unable to reproduce this issue using Bun 1.3.10.

Summary

This is a crash report for a segfault in Bun__JSTimeout__call (NodeTimerObject.cpp:57) during timer callback execution on Bun v1.3.10 (macOS Silicon). The reporter provides no specific reproduction steps -- the crash happened "during fixing atuin installation using claude agent."

Crash Analysis

The crash address 0xFFFE000000000074 is a NaN-boxed JSC integer value (integer 116), not a valid memory pointer. This indicates a use-after-GC scenario where a JSValue that previously pointed to a JS object was garbage-collected and the memory was overwritten.

Stack Trace

llint_call_javascript
  -> JSC::Interpreter::executeCallImpl
    -> Bun__JSTimeout__call (NodeTimerObject.cpp:57)
      -> bun.js.event_loop.tickImmediateTasks
        -> bun.js.jsc.OpaqueWrap.callback
          -> JSC__VM__holdAPILock
            -> cli.Cli.start -> main

Root Cause (Code Analysis)

The crash originates in TimerObjectInternals.zig:fire() (lines 170-183):

1. Line 133: this_object = this.this_value.tryGet() -- retrieves the JS timer object
2. Lines 148-153: callback, arguments extracted as local JSValues from cached properties of this_object
3. Line 171: For setTimeout, this.this_value.downgrade() converts the strong GC **** to a weak reference -- allowing GC to collect the object
4. Line 175: this_object.ensureStillAlive() -- compiler barrier, but may not prevent GC of internal properties
5. Line 183: this.run(...) calls into Bun__JSTimeout__call which calls profiledCall with the potentially-stale callbackValue

The downgrade() pattern was introduced in commit 9d5a800c3d ("fix(napi,timers): callback scope #27026") which is tagged as bun-v1.3.10 -- the exact version the **** is on.

Related Fix Since v1.3.10

Commit 1b982511c3 ("fix(timers): use-after-finalize crash in setImmediate cleanup paths") addresses a related but different code path -- where downgrade() was called on an already-finalized JSRef in cleanup paths (tryGet returning null, and cleared/unref'd immediates). This fix replaced downgrade() with deinit() in those cleanup paths.

However, the main crash path (downgrade before run at line 171, allowing GC to collect during profiledCall) appears to still be present in the current codebase.

Reproduction Attempts

What was tried

1. Analyzed the crash report at bun.report -- identified the crash in Bun__JSTimeout__call at line 57
2. Traced the code path from the Zig timer internals through the C++ profiledCall
3. Identified the downgrade() before run() pattern as the likely **** cause
4. Checked git history -- found one related fix (1b982511c3) for cleanup paths, but the main fire path is unchanged
5. Checked version: The JSRef change (9d5a800c3d) is in v1.3.10, confirming the reporter's version contains this code

Why reproduction is not feasible

• No reproduction steps provided -- the reporter says it "happened during fixing atuin installation using claude agent"
• GC timing dependent -- this crash requires a garbage collection cycle to happen in the narrow window between downgrade() (line 171) and profiledCall (NodeTimerObject.cpp:57)
• Non-deterministic -- depends on memory pressure, allocation patterns, and GC scheduling
• Application-specific -- occurred during a complex workload (Claude Code CLI) with many active features (fetch, WebSocket, spawn, http_server, etc.)

Bun version tested

Current codebase: v1.3.11 (commit 32edef7)

Assessment

This appears to be a real but non-deterministic GC-related bug in the timer code. The downgrade() at TimerObjectInternals.zig:171 before run() at line 183 creates a window where GC can collect the timer object and its cached callback/arguments values. The fix in 1b982511c3 addressed related cleanup paths but not the main execution path.

The issue cannot be reliably reproduced without specific steps, but the code analysis strongly suggests the bug is still present in v1.3.11.

This is an automated comment. If you can provide additional reproduction steps or a minimal reproduction repository, please update this issue.

[github-actions]

Found 3 possible duplicate issues:

1. Segmentation fault at address 0x204 on Bun 1.3.9 (macOS) #27000
2. Segmentation fault after long-running session (v1.3.9-canary.51) #26984
3. Bun Segmentation Fault after heavy use w/ long runtime and memory usage #27715

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