[Bug] 0.27.0 web server process repeatedly dies with SIGSEGV in V8 GC marking — 6 crashes in ~26 h

[ping1999]

What version of Kimi Code is running?

0.27.0 (self-contained binary at ~/.kimi-code/bin/kimi, bundled Node.js v24.15.0; binary installed 2026-07-18)

Which open platform/subscription were you using?

Kimi Code subscription (managed:kimi-code, OAuth)

Which model were you using?

kimi-code/k3, thinking effort max

What platform is your computer?

Linux x86_64 (Arch Linux, kernel 7.0.14-zen), 23 GiB RAM. Running in web server mode (kimi server, bound to 0.0.0.0).

What issue are you seeing?

The kimi web server process dies abruptly with SIGSEGV — 6 crashes in ~26 hours, all with the same signature: the faulting threads are always inside V8 garbage-collection marking.

Crash timeline (times UTC+8, all SIGSEGV, coredumps preserved):

#	Time	Signal
1	2026-07-19 12:04:03	SIGSEGV
2	2026-07-20 11:21:08	SIGSEGV
3	2026-07-20 11:22:18	SIGSEGV
4	2026-07-20 11:22:55	SIGSEGV
5	2026-07-20 13:43:03	SIGSEGV
6	2026-07-20 13:49:18	SIGSEGV

Stack traces (via coredumpctl, crashes #5 and #6):

Main thread — incremental marking:

#0  v8::internal::MarkingVisitorBase<v8::internal::MainMarkingVisitor>::ProcessStrongHeapObject<v8::internal::FullHeapObjectSlot>
#1  v8::internal::BodyDescriptorBase::IteratePointers<v8::internal::MainMarkingVisitor>
#2  v8::internal::MarkCompactCollector::ProcessMarkingWorklist<...>
#3  v8::internal::IncrementalMarking::Step
#4  v8::internal::IncrementalMarking::AdvanceAndFinalizeIfComplete
#5  v8::internal::IncrementalMarkingJob::Task::RunInternal
#6  node::PerIsolatePlatformData::RunForegroundTask
#7  node::PerIsolatePlatformData::FlushForegroundTasksInternal
#8  uv__async_io → uv__io_poll → uv_run
#9  node::SpinEventLoopInternal → node::NodeMainInstance::Run → node::Start

V8Worker threads (several per crash) — concurrent marking:

#0  v8::internal::MarkingVisitorBase<v8::internal::ConcurrentMarkingVisitor>::ProcessStrongHeapObject<v8::internal::FullHeapObjectSlot>
    (frame #0 varies: also VisitMapPointer and MarkBit::Set)
#1  v8::internal::BodyDescriptorBase::IteratePointers<v8::internal::ConcurrentMarkingVisitor>
#2  v8::internal::ConcurrentMarking::RunMajor
#3  v8::internal::ConcurrentMarking::JobTaskMajor::Run
#4  v8::platform::DefaultJobWorker::Run
#5  node::(anonymous namespace)::PlatformWorkerThread

Logging at crash time:

• ~/.kimi-code/logs/kimi-code.log contains only startup and oauth lines — nothing is logged at the crash instant; the process dies at native level with no JS error and no shutdown entry.
• ~/.kimi-code/server/server.log is empty (0 bytes).

What steps can reproduce the bug?

Unknown — intermittent. Occurs during normal web-mode usage with active sessions (6 occurrences in ~26 h, including 3 within 2 minutes). No specific user action identified as a trigger.

What is the expected behavior?

The web server process should not crash with a native SIGSEGV. If this matches a known V8/Node issue, guidance on a workaround (runtime flags, config) would be appreciated.

Additional information

• Not OOM: no OOM-killer records in dmesg/journal; ~16 GiB of 23 GiB RAM free at check time.
• Crashes started the day after the 0.27.0 binary was installed (installed 2026-07-18 15:15 local; first crash 2026-07-19 12:04).
• The machine rebooted once on 2026-07-20 12:03 local time; crashes fix: correct Anthropic provider inputOther token counting #2–fix: remove abort listener leak in abortableSleep #4 happened before the reboot, fix: clear reverseRpcDisposers array after disposing handlers #5–fix: use atomic write for tui.toml config to prevent corruption #6 after, with an identical stack signature.
• Also on 2026-07-20, a separate, unrelated Node.js v22.23.1 binary on the same machine crashed 4 times with the same V8 concurrent-marking stack signature, and other processes (chrome, gnome-shell, kwin_wayland, python) segfaulted as well — 19 coredumps in total that day. This may point to a machine-level contributor, but the kimi-code web server is the most frequently affected process, so I am reporting it with full data either way.
• All 6 coredumps are preserved (core.kimi-code.*.zst, 24–56 MB each). I can provide coredumps or an /export-debug-zip archive on request.