[Bug] dsh web auto-exits with SIGSEGV (signal 11) while idle on 0.2.2-rc.1

[bwcx-jzy]

Summary

dsh web exits by itself with Segmentation fault (core dumped) while it is idle — no user operation is being performed and no command is being sent. Port 3080 stops listening, but the VM itself stays alive: SSH remains usable and there is no kernel panic, OOM kill, or GPF.

Environment

• dsh: 0.2.2-rc.1 (global install)
• Node: v24.14.1
• OS: Ubuntu 26.04
• Kernel: 7.0.0-43-generic
• VM: Proxmox KVM, 12 vCPU, 28 GiB RAM, 8 GiB swap (swapfile on a dedicated NVMe data disk), RTX 2080 Ti passthrough
• Concurrent workloads: several VSCode windows, llama-server, whisper-server, openclaw gateway, docker containers, GNOME desktop

Symptom

• The dsh web process was running normally and idle.
• It exited on its own with the shell message Segmentation fault (core dumped).
• Port 3080 stopped listening; the VM itself stayed up.
• I manually restarted dsh web at 09:27:22 (new PID 767241). The old process PID was 6480.

Evidence

From /var/log/apport.log:

INFO: apport ... 2026-11-08 06:33:52,301: called for global pid 6480, signal 11, core limit 0, dump mode 1
INFO: apport ... executable: /home/user/.nvm/versions/node/v24.14.1/bin/node
    (command line "node /home/user/.nvm/versions/node/v24.14.1/bin/dsh web")
ERROR: apport ... executable does not belong to a package, ignoring

So:

• The old dsh web process (PID 6480) received SIGSEGV / signal 11 at 06:33:52.
• core limit was 0.
• apport classified the nvm-managed node binary as an unpackaged executable and ignored it. No /var/crash report and no core file were produced.
• coredumpctl / systemd-coredump is not installed; /var/lib/apport/coredump is empty.
• No node ... segfault at ... line appears in the kernel journal.
• The VM stayed up: no OOM, no general protection fault, no kernel lockup.

The process was down from 06:33 until 09:27. The current dsh web (PID 767241) is running and has been stable so far.

Relation to #12581

This may be related to the high-frequency dsh-subprocess/git-scanning behavior reported in #12581, but the failure mode here is different: in this case the dsh web process itself crashes with SIGSEGV while the VM remains healthy, rather than the VM freezing from memory exhaustion. Cross-linking for context.

Questions

1. Is a spontaneous SIGSEGV in dsh web known on 0.2.2-rc.1? Are there known native/V8 crash paths (node-pty, sharp, sherpa-onnx, etc.)?
2. How can we capture a useful backtrace when Node is installed under nvm and apport ignores unpackaged executables? Is running under gdb or changing kernel.core_pattern the recommended approach?
3. Would 0.2.1-rc.5 avoid this crash? I am considering a rollback as a controlled comparison.
4. Is there a recommended supervisor/restart strategy for dsh web on a long-running dev server?

[bwcx-jzy]

Additional context from a local investigation (2026-11-08):

• The Web profile has both @deepseek-ai/dsh-experimental-forge-bundle and the standalone @deepseek-ai/dsh-experimental-tool-worktree in dsh.profile.bundles. cordis.patch.yml does not disable either. The forge README warns that profiles that already selected the standalone worktree bundle should follow the upgrade guide before enabling forge — this profile has that duplicate/conflicting composition.
• The exact git commands in the subprocess bursts (rev-parse --path-format=absolute --git-common-dir, symbolic-ref --quiet --short HEAD, remote -v, etc.) appear in @deepseek-ai/dsh-experimental-client-ui-forge/lib/index.js. Its inspectCheckout() runs 7 git commands per checkout; with ~28 previously opened workspaces, 28 × 7 × a few refresh passes ≈ 546, which matches the observed count.
• This strongly points to the forge panel as the source of the high-frequency git subprocess storm. The 06:33 SIGSEGV itself still has no backtrace: apport ignored the nvm-managed node binary as unpackaged and core limit was 0, so the SIGSEGV root is not yet proven.
• I am testing by disabling the forge bundle (and the duplicate standalone worktree bundle), restarting dsh web, and monitoring subprocess count and crashes.

[bwcx-jzy]

Follow-up: the dsh web SIGSEGV recurred at 11:45:11 (PID 107189, signal 11) after the experimental forge bundle had already been removed from the Web profile at 10:35 — before this dsh web process started (~10:36).

So:

• @deepseek-ai/dsh-experimental-forge-bundle is not required for this SIGSEGV. It may explain the earlier high-frequency git subprocess storm, but removing it did not stop the dsh web crash.
• Current profile has only the standalone @deepseek-ai/dsh-experimental-tool-worktree; dsh is still 0.2.2-rc.1 / Node v24.14.1.
• apport again recorded signal 11, core limit 0, classified the nvm node binary as unpackaged and ignored it, so there is still no core/backtrace.
• The VM stayed up; no OOM/GPF/kernel lockup in this event.

I am rolling back dsh to 0.2.1-rc.5 and will report whether the SIGSEGV stops.

[bwcx-jzy]

New failure mode: dsh web now aborts with glibc corrupted size vs. prev_size (heap corruption, SIGABRT / signal 6), not only SIGSEGV.

Apport timeline (all core limit 0, all ignored as unpackaged, no core):

• 18:46:08 PID 341256 signal 11
• 22:08:12 PID 73231 signal 6 (dsh web --host 127.0.0.1 --port 0 --no-open)
• 22:10:31 PID 10518 signal 11
• 22:20:24 PID 97199 signal 6

Also, a separate kernel lookup_swap_cgroup_id GPF occurred at 22:16:58 on 7.0.0-43.

The forge bundle is already removed; the profile only has the standalone @deepseek-ai/dsh-experimental-tool-worktree. Current dsh (PID 188749) has loaded native modules sharp-linux-x64.node, koffi.node, node-addon-require-builtin...node, and system.node, so the heap corruption is likely in a native addon / Node 24 interaction rather than the forge panel.

I am rolling back to 0.2.1-rc.5 and will try to capture a core/backtrace with gdb (handle SIGABRT/SIGSEGV stop, bt full), because apport is useless for the nvm-managed node binary.

[bwcx-jzy]

Follow-up with a captured core and a Node-version investigation.

Core captured

We now have a core for a dsh web SIGSEGV (after routing kernel.core_pattern to a file instead of apport):

Program terminated with signal SIGSEGV, Segmentation fault.
#0  v8::internal::BodyDescriptorBase::IteratePointers<
        v8::internal::IterateAndScavengePromotedObjectsVisitor>(...)
Thread 1: ... v8::internal::Heap::Scavenge()
Thread 2: ... v8::internal::Scavenger::Process()
Thread 13: ... node-pty/prebuilds/linux-x64/pty.node
            SetupExitCallback(...) ... wait4

The crash is in V8 Scavenger / GC, not in a directly-visible native-addon frame, but the core contains a node-pty native thread. Profile currently has @deepseek-ai/dsh-experimental-terminal-bundle enabled. The experimental forge bundle was already removed earlier; the crash still occurs.

Versions

• dsh: 0.2.2-rc.1
• Node currently running: v24.14.1 (V8 13.6.233.17-node.44, modules 137)
• Node 24.21.0 is installed locally (V8 13.6.233.17-node.53, same V8 baseline)
• Node 26.13.0 "Lithium" LTS is available upstream
• dsh engines.node: >=24.9.0
• Native modules loaded by the process: node-pty 1.2.0-beta.15, sharp 0.35.5, koffi 3.1.1, node-addon-require-builtin, system.node

Questions

1. Is node-pty 1.2.0-beta.15 tested/supported with dsh 0.2.2-rc.1 on Node 24.14.1? Could its native thread corrupt the V8 heap, producing this Scavenger SIGSEGV?
2. Is Node 26.13 LTS within the supported range? engines says >=24.9.0; would upgrading from 24.14.1 (V8 13.6) to 26.13 (newer V8) be the recommended next step, or should we stay on Node 24 LTS?
3. Is disabling @deepseek-ai/dsh-experimental-terminal-bundle (removing node-pty) a valid workaround to confirm/avoid this crash?
4. Is this related to any known Node 24.14.x / V8 concurrent-scavenger issue?

[PerryLink]

node-pty loads lazily; the native versions did not change.

That reframes question 1 and the rollback in question 3.

subprocess-local does not import node-pty eagerly: it builds a lazy require at packages/subprocess/subprocess-local/src/index.ts:55 (createLazyRequire('node-pty', import.meta.url)) and only touches it when a terminal spawns. The terminal bundle itself ships switched off in Web and Desktop (packages/experimental/terminal-bundle/README.md:12). So your core's node-pty/prebuilds/linux-x64/pty.node thread means that process had spawned a PTY at some point — disabling the bundle is a valid A/B only for a run where no terminal is opened. If the crash recurs with zero terminals, the bundle is not the variable.

The versions also match: node-pty 1.2.0-beta.15, koffi 3.1.1 and sharp 0.35.5 are identical in dsh-v0.2.1-rc.5, dsh-v0.2.2-rc.1 and fcc0ad46. Rolling back to rc.5 will not change a native module; it changes the composition. If you want a clean discriminator, A/B the Node runtime instead (24.14.1 against 24.21/24.22) — the crash is in V8's Scavenger, and your core already shows a foreign native thread in the same heap.

On the four questions: I cannot confirm a known V8 24.14 crash from here, and the scavenger frame with a native thread is exactly the shape to report upstream rather than to explain from the harness. For the core, your kernel.core_pattern change is the right move; for a service, also raise LimitCORE (systemd) because core limit 0 is what apport respected. There is no built-in restart for dsh web; use Restart=on-failure in a unit, or a supervisor that restarts on signal 11/6, and keep the core pattern outside apport.

One harness-side note: DSH cannot catch this. A SIGSEGV in the scavenger is below the JS layer, so a try/catch or a stream guard will not turn it into an error.

[bwcx-jzy]

Thanks for the pointers above. Following the suggestion to A/B the Node runtime: it is not fixed by the Node 24 patch level, and we now have cores for three crashes, all in V8's scavenger.

Summary: the harness is unchanged across this A/B (dsh 0.2.2-rc.1, same profile). Only the Node binary differs.

Node	V8	Result
v24.14.1	13.6.233.17-node.44	4 crashes on 2026-11-10: 11:34, 16:08, 17:28, 18:00 (intervals 31 min – 3.5 h)
v24.22.2	13.6.233.17-node.63	crashed after 4 h 20 min (22:22)
v26.13.0	14.6.202.34-node.40	started 22:28, observing

24.22.2 is not bare: it ships several V8 backports, so this isn't a "same binary" comparison. Still crashes.

Environment / evidence setup

• kernel.core_pattern → file (outside apport); LimitCORE unlimited for the dsh web process. Working.
• Kernel currently 7.0.0-31; the crashes also occurred on -43/-44, so it is not kernel-version-bound.
• No OOM kill, no GPF, no kernel panic. Process RSS ~2 GB of 30 GB. dsh web has no built-in restart — manual restart per crash, not a supervisor problem.
• Three dsh cores captured, all SIGSEGV inside V8 scavenger. Two representative backtraces:

# 2026-11-10 18:00, Node v24.14.1
SIGSEGV; NT_SIGINFO si_code = -6 (SI_TKILL — signal re-raised by the process itself)
#0  v8::internal::FreeListManyCached::RemoveCategory(FreeListCategory*)
#1  v8::internal::PagedSpaceBase::RemovePage(PageMetadata*)
#2  v8::internal::PagedSpaceBase::RemovePageSafe(int)
#3  v8::internal::PagedSpaceAllocatorPolicy::RefillLab(int, AllocationOrigin)
#4  v8::internal::MainAllocator::AllocateRawSlow(int, AllocationAlignment, AllocationOrigin)
#5  v8::internal::Scavenger::EvacuateShortcutCandidate<FullHeapObjectSlot>(..., Tagged<ConsString>, ...)
#6  v8::internal::BodyDescriptorBase::IteratePointers<IterateAndScavengePromotedObjectsVisitor>(...)
#7  v8::internal::Scavenger::IterateAndScavengePromotedObject(...)
#8  v8::internal::Scavenger::Process(...)

# 2026-11-10 22:22, Node v24.22.2
#0  v8::internal::FreeListManyCached::RemoveCategory(FreeListCategory*)
#1  v8::internal::PagedSpaceBase::RemovePage(PageMetadata*)
#2  v8::internal::PagedSpaceBase::RemovePageSafe(int)
#3  v8::internal::PagedSpaceAllocatorPolicy::RefillLab(int, AllocationOrigin)
#4  v8::internal::MainAllocator::AllocateRawSlow(int, AllocationAlignment, AllocationOrigin)
#5  v8::internal::Scavenger::EvacuateInPlaceInternalizableString<FullHeapObjectSlot>(..., Tagged<String>, ...)
#6  v8::internal::VisitSpillSlots(...)
#7  v8::internal::CommonFrame::IterateTurbofanJSOptimizedFrame(...)
#8  v8::internal::Isolate::Iterate(...)
#9  v8::internal::Heap::IterateRoots(...)
#10 v8::internal::ScavengerCollector::CollectGarbage()
#11 v8::internal::Heap::Scavenge()

On the 18:00 core the faulting instruction is mov (%rax),%rdi with rax = 0x49533168 — garbage that looks like ASCII, not a pointer. In both cases the scavenger is evacuating a string and refilling a LAB; the free-list page metadata it walks is already corrupted.

Behaviour notes

• The crash tracks allocation pressure rather than pure idleness: the 22:22 crash happened 2 seconds after a subprocess finished (54 s CPU / ~762 MB peak). Earlier crashes also followed bursts of sessions/subprocesses, with the process sitting idle in between.
• 12–13 threads per core; V8 platform worker threads are concurrently inside Scavenger::Process, i.e. concurrent scavenger is active.
• Native modules in the crashing processes: node-pty (lazy — one process had spawned a PTY), sharp 0.35.5, koffi 3.1.1, node-addon-system, node-addon-require-builtin. Per the note above, the node-pty A/B is only meaningful for a run with no PTY spawns; we keep that as a separate experiment.

Questions

1. Is a crash in FreeListManyCached::RemoveCategory during scavenger LAB refill (concurrent scavenger active) a known V8 issue on the 13.6 line?
2. Is there a V8 flag worth testing as a mitigation/discriminator — e.g. disabling concurrent scavenger, changing --max-semi-space-size, or running with --stress-scavenge to reproduce faster?
3. We are filing this on nodejs/node with these core backtraces. Anything else you would want included?

[aturzone]

Thanks for the cores and the three-version A/B — that is what makes this reportable.

1. Known on 13.6? I found no public report with this signature. The only hit for the top frame is a V8 TSAN data race in that function (https://issues.chromium.org/issues/434137274, 2025-07-25, regression window ending at V8 main r101632): RemoveCategory → EvictFreeListItems → RefillFreeList. Different path and later V8 revision — a lead, not an identification. Treat "known" as unproven.

The frames show: RemovePageSafe locks the space, asks the free list for a page, then RemovePage → UnlinkFreeListCategories → RemoveCategory, which relinks the cached category. rax=0x49533168 means a pointer slot already held non-pointer data. The scavenger is the victim — it was promoting into old space and touched an old-space free list that was already inconsistent. That fits the 2 s-after-subprocess crash and idle gaps: the damage can predate the crash and lands on whichever allocation next walks the list. So --no-parallel-scavenge changes which allocation trips over the damage, not whether damage exists; persistence does not prove "not a race".

2. Flags. --concurrent-scavenge and --no-concurrent-scavenge do not exist in 24.22.2 — both are bad option. The real knob is --no-parallel-scavenge (verified: it zeroes background.scavenge.parallel); --single-threaded-gc is the broader version. --stress-scavenge=N needs an int; bare --stress-scavenge is rejected.

--max-semi-space-size=8/16/32 moves the wrong way. Default max new-space capacity is already 64 MB (scavenger-max-new-space-capacity-mb=32, doubled because the official linux-x64 build has pointer compression off); those values cap it to 8-32 MB, i.e. more scavenges. It is only a ceiling; new space starts at 1 MB. To enlarge it, set a floor: --min-semi-space-size=32 --max-semi-space-size=64, and confirm new_space_capacity= in the trace.

Among these, only --max-semi-space-size (and --max-old-space-size) survive NODE_OPTIONS; --trace-gc, --stress-scavenge, --single-threaded-gc, --no-parallel-scavenge and --min-semi-space-size are rejected. So:

node --no-parallel-scavenge --trace-gc "$(npm root -g)/@deepseek-ai/dsh/lib/bin.js" web

Priority: (1) --no-parallel-scavenge: removes the parallel scavenger workers — the crash either stops (concurrency lead) or persists with the same frames (axis ruled out). (2) --single-threaded-gc: separates concurrent marking/sweeping from scavenge parallelism. (3) --min-semi-space-size floor: diagnostic; changes scavenge/promotion rate; costs ~32 MB. (4) --stress-scavenge=50..100: repro accelerator only, 16x slower on a microbenchmark here. (5) --no-sparkplug: not indicated by your frames, but it is the known workaround for a different 13.6 GC crash (nodejs/node#62393); one arm rules it out.

Matrix: 24.22.2, same profile, no PTY, one arm at a time, 48 h or 3 crashes; repeat A0 last:

Arm	Extra args	Tests
A0	none	baseline
A1	--no-parallel-scavenge	parallel scavenger
A2	--single-threaded-gc	all background GC
A3	--min-semi-space-size=32 --max-semi-space-size=64	fewer scavenges
A4	--max-semi-space-size=8	more scavenges
A5	--stress-scavenge=100	per-scavenge repro
A6	--no-sparkplug	rules out #62393

48-72 h per arm is the minimum to claim a change. Capture per arm: last --trace-gc lines, core, process.execArgv, addon list.

node-pty: that thread only proves a PTY was spawned; subprocess-local lazy-requires node-pty and the terminal bundle ships off in Web, so the rc.5 rollback changes composition, not native modules — a separate no-PTY arm, not the main hypothesis.

3. nodejs/node. Beyond backtraces: full process.versions; process.config.variables (pointer compression, sandbox, official build); exact flags (NODE_OPTIONS flags do not appear in process.execArgv); official vs distro build; kernel and glibc; core_pattern, ulimit -c, core producer; readelf -n core and build-id; bt, info registers, x/i $pc, info threads, and the page/category arguments; RSS and heap at crash; addon inventory with versions and build-ids; a --no-addons or minimal-profile run. Include the glibc corrupted size vs. prev_size SIGABRTs — two allocators showing corruption points at a stray write, not scavenger accounting.

On si_code=-6: I reproduced both cases here — raise(SIGSEGV) gives -6, si_pid = self, and stops in pthread_kill; a real null deref gives 1 with si_addr. V8 13.6's wasm trap handler only re-raises user-generated signals. So that core's NT_SIGINFO is likely second-generation (debugger re-injection or a crash handler). Print p $_siginfo and _sifields._kill.si_pid, paste the untrimmed bt, and state how each core was produced; don't quote si_addr.

Uncertainty: no local reproduction, no 13.6 fix identified, chromium page not fetchable here. If 26.13 stays clean past ~3x the 24.22.2 MTBF, that is the strongest signal so far.