#5604 3.7b: server SIGSEGV in spawn_pane (child side of fork, pre-exec) on a long-lived, high-session-count server

tmux 3.7b: SIGSEGV in spawn_pane (child side of fork, pre-exec) on a long-lived large server

Summary

A tmux server that had been running for 14 days with ~60 sessions / ~121 panes died with SIGSEGV while spawning a pane. macOS's crash reporter annotates the crash as occurring on the child side of fork, before exec.

Environment

tmux 3.7b (Homebrew)
macOS 26.6.2 (build 25G83), arm64 (MacBookPro18,4)
Server uptime at crash: ~14 days
Load at crash: ~60 sessions, ~121 panes, history-limit 50000
Not resource exhaustion: ~75% system memory free; 847 user procs against a kern.maxprocperuid of 10666; kern.maxfilesperproc 245760

Exception

exception: EXC_BAD_ACCESS (SIGSEGV)
codes:     KERN_INVALID_ADDRESS at 0x00000000000002e0
termination: SIGNAL 11 (Segmentation fault: 11)
asi: libsystem_c.dylib: ["crashed on child side of fork pre-exec"]

The faulting address 0x2e0 is a small offset from NULL, consistent with a dereference through a null struct pointer.

Backtrace (triggered thread, com.apple.main-thread — the only thread)

tmux  input_free + 217440            <- symbolication is nearest-preceding-export;
tmux  spawn_pane + 394384               the large offsets mean these frames are
tmux  cmd_respawn_pane_exec + 86992     approximate, not literal
tmux  cmdq_next + 79812
tmux  server_loop + 378652
tmux  proc_loop + 305336
tmux  server_start + 377252
tmux  client_main + 20924
tmux  main + 419260
dyld  start + 132324

The path server_loop -> cmdq_next -> cmd_respawn_pane_exec -> spawn_pane plus the "child side of fork pre-exec" annotation points at the window between fork() and exec() inside spawn_pane().

Notes / caveats

Symbol offsets are very large, so frame names are the nearest preceding exported symbol rather than the true functions. Frame 0 in particular is almost certainly not input_free.
I do not have a deterministic reproducer. The pattern is: a very long-lived server under sustained automated pane spawn/respawn, at high session count.
A crash in the forked child alone would normally leave the parent alive, but the server was gone afterward (no server running on <socket>), so the parent did not survive either.

Attachments available

Full macOS .ips crash report can be provided.

Related, but I believe distinct

#5499 (Server SIGSEGV after respawn-pane when a control client is behind on the pane, closed 2026-08-18) also involves respawn-pane. I do not think this is the same issue: there was no control-mode client (-C/-CC) attached here — only ordinary attach-session clients — and this is 3.7b, which postdates that fix. Flagging it in case the respawn path is a common factor.

Config notes

The server ran a generated config; the settings most likely to be relevant: history-limit 50000, mouse on, escape-time 0, focus-events on, plus display-menu/run-shell -b bindings. Panes were spawned programmatically by a supervisor process, which is why respawn/spawn traffic was continuous.