[BUG] Recurring SIGSEGV on `HTTP Client` thread during SSE streaming — tagged JSValue dereferenced as pointer (Bun 1.4.0, macOS arm64, 2.1.220)

Status Open

Reported on v2.1.220

Maintainer reply None cached

Activity 0 comments · opened Aug 15, 2026

Summary

Two SIGSEGV crashes in three days, both on the HTTP Client thread, both dereferencing what looks like a tagged JSC JSValue as a raw pointer. Both happened mid-session while an assistant response was streaming (the last debug line before the crash is the SSE first-byte log). The lower half of the faulting stack is byte-identical between the two crashes, so this is one code path, not random heap damage.

This looks related to but distinct from #78650 (that one is address 0x4 in the socket GC finalizer, triggered simultaneously across all sessions by a macOS deep-sleep wake). Here there is no sleep/wake event, only one session crashes at a time, and the faulting addresses carry high tag bits rather than being near-null.

Environment

Claude Code 2.1.220 (VS Code extension, anthropic.claude-code-2.1.220-darwin-arm64, resources/native-binary/claude)
Bun v1.4.0 (f6d0fcd24), bundled
macOS 26.5.2 (25F84), MacBook Pro MacBookPro18,4 (M1 Max), arm64, 64 GB RAM
Parent process: Code Helper (Plugin) (VS Code), same pid across both crashes
Model: claude-opus-5[1m]; flags include --output-format stream-json --input-format stream-json --include-partial-messages --max-thinking-tokens 31999
Binary UUID (both crashes): 4c4c443f-5555-3144-a14b-f1f02f402ba3, image size 63258624

Crash details

| | Crash A | Crash B |
|---|---|---|
| Time (UTC+3) | 2026-08-13 14:06:35 | 2026-08-15 14:02:46 |
| Process uptime at crash | 2 h 28 m | 1 h 40 m |
| Signal | SIGSEGV / EXC_BAD_ACCESS | SIGSEGV / EXC_BAD_ACCESS |
| Faulting thread name | HTTP Client (idx 7) | HTTP Client (idx 8) |
| Fault address | 0xff00000000ed0007 | 0x0008020000b10250 |
| macOS subtype | KERN_INVALID_ADDRESS at 0xff00000000ed0007 -> 0x0000000000ed0007 (possible pointer authentication failure) | KERN_INVALID_ADDRESS at 0x0008020000b10250 -> 0x0000020000b10250 (possible pointer authentication failure) |

Both fault addresses have a valid-looking low half with non-zero high bits — 0xff00_00000000_ed0007 and 0x0008_02000_0b10250. That is the shape of a JSC-encoded value (NaN-boxing / tag bits), not a heap pointer, which suggests a JSValue is reaching a code path that dereferences it as a pointer — i.e. a use-after-collect or a missing unwrap on the HTTP/stream path.

Faulting stacks (frames 0–6 are Bun's own handler → `raise` → `_sigtramp`; frame 7 is the real fault site)

Crash A (2026-08-13):

  7 claude 0xce20c8      <- fault
  8 claude 0xfbf950
  9 claude 0x7fef30
 10 claude 0x7f64e8
 11 claude 0x7f7200
 12 claude 0x7faca4   ┐
 13 claude 0x7f8dec   │
 14 claude 0x7f92c0   │
 15 claude 0x1504000  ├── identical tail in both crashes
 16 claude 0x1500f74  │
 17 claude 0x1501620  │
 18 claude 0x1e352bc  ┘
 19 libsystem_pthread.dylib 0x6c58 _pthread_start
 20 libsystem_pthread.dylib 0x1c1c thread_start

Crash B (2026-08-15):

  7 claude 0xfbdf2c      <- fault
  8 claude 0xfbdf2c      (same offset twice — recursion or inlined frame)
  9 claude 0x7f7640
 10 claude 0x7f724c
 11 claude 0x7faca4   ┐
 12 claude 0x7f8dec   │
 13 claude 0x7f92c0   │
 14 claude 0x1504000  ├── identical tail
 15 claude 0x1500f74  │
 16 claude 0x1501620  │
 17 claude 0x1e352bc  ┘
 18 libsystem_pthread.dylib 0x6c58 _pthread_start
 19 libsystem_pthread.dylib 0x1c1c thread_start

The shared tail 0x7faca4 → 0x7f8dec → 0x7f92c0 → 0x1504000 → 0x1500f74 → 0x1501620 → 0x1e352bc is the same in both, so both crashes enter through the same HTTP-client loop and diverge only in the last 2–4 frames. Note 0x7faca4 and 0x7f8dec appear in both.

stderr at the moment of crash (Crash B)

[DEBUG] [API:timing] dispatching to firstParty model=claude-opus-5[1m]
[DEBUG] [API REQUEST] /v1/messages x-client-request-id=… source=sdk
[DEBUG] Stream started - received first chunk
[DEBUG] [API:timing] first byte after 1307ms
============================================================
Bun v1.4.0 (f6d0fcd24) macOS Silicon
…
Elapsed: 6025267ms | User: 156448ms | Sys: 16060ms
RSS: 0.47 GB | Peak: 0.54 GB | Commit: 0.52 GB | Faults: 2445
panic: Segmentation fault at address 0x8020000B10250

So the crash lands ~immediately after the first SSE byte of a new streamed response, not at idle.

bun.report URL emitted by Crash B:
https://bun.report/1.4.0/M_1f6d0fcdmgggkEuhogC21wlqB2yvvf+j79P2k59Pmq2+P2+m+P+rp+P+//gqBm3ngqB+hrgqB2rpt8B__A2gghgBglhkW

What may make it more likely

Reporting these because they may be relevant to reproduction, not as a claimed cause:

Long-lived processes. Both crashes were 1 h 40 m and 2 h 28 m into the process. Short sessions on this machine have not crashed.
Large resident context. This project loads a ~134 KB instruction file plus rules every session, on the 1M-context model, so heap pressure is high and sustained.
Machine was under memory pressure. vm.swapusage at inspection time: total 6144M used 4883M free 1261M, with several older claude processes still resident (one 16 days old, one 8 days old).

Not applicable here

No sleep/wake event around either crash (unlike #78650).
Only one session crashed each time, not all concurrently.
RSS at crash was 0.47 GB with peak 0.54 GB, so this is not the process exhausting its own memory.

Expected

Streaming a response should not be able to segfault the CLI.

View original on GitHub ↗