2 Commits

Author	SHA1	Message	Date
JianFeeeee	b4fb254bf5	fix(proc): 修 arena use-after-unmap 导致的内核 SIGSEGV（关停竞态） ... ## 症状 全量 go test 偶发 SIGSEGV，整个测试二进制被杀（recover 捕不到 runtime 致命错误）。崩溃栈（2026-09-25 实测捕获，完整）： readLoop (process.go:334) → markExited → once.Do → onExit → Plugin.handleExit (plugin.go:209) → Host.ReclaimOwner (host.go:342) → arenaRegion.ReclaimOwner → blockBase → getU32 → SIGSEGV 读已 munmap 的内存 ## 根因（两个叠加缺陷，同一后果） **① markExited 里 close(exited) 早于 onExit** close(p.exited) // :394 —— 先关闭，唤醒所有等待者 p.sup.untrack(p.name) p.onExit(...) // :399 —— 回调里要读共享内存 onExit（内核侧 Plugin.handleExit）会调 Host.ReclaimOwner 回收该插件残留的 共享槽，那是要读共享内存区域的。而 exited 一关闭，Stop()/Kill() 就返回 （process.go:566/587），StopAll 随即返回，调用方（Host.Close）立刻 freeShm 解除映射 —— 此刻 onExit 还没跑完，ReclaimOwner 就成了读已 munmap 的内存。 修法：把 onExit 提到 close(p.exited) **之前**，并明确 exited 的语义是 「**完全**收尾完毕」而非「进程已死」——任何等待者看到它关闭后，都可安全 释放共享内存、卸载资源。 **② StopAll 超时分支 `go p.Kill()` 发射后不管** go p.Kill() // 不等待 本函数返回后调用方就 unmap，而 Kill 内部要等 markExited 跑完（含 onExit）。 改为等全部 Kill 完成（Kill 自带 killReapTimeout 上限，不会无限拖住关停）。 **③ 同类的第三处：事件环订阅在关停时从不退订** EventRing.Subscribe 注册到 Bus 的 handler 会 ring.WritePush（写共享内存）， 而 Host.Close 会 munmap 整块区域。此前： - handleEvents 把 EvtRingSubscribe 的取消函数**直接丢弃**（corehandler_runtime.go:103） - EventsUnsubscribe 是 no-op，注释还写着「子进程 Stop 时由内核统一清理」， 但 closeProcHost 根本没有退订 于是每个订阅过的插件都在 Bus 上永久留了一个写共享内存的 handler， munmap 后任意一条事件经过 Publish 就会写已解除映射的内存 ⇒ 同类 SIGSEGV。 修法：EventRing 记为 unsubs、新增 EvtRingSubscribeTracked（订阅即登记）， Host.Close 在 freeShm **之前**调用 evtCloser.Close 统一退订。 ## 回归测试（3 个，均经变异验证「修复前判红」） 1. `TestProcess_OnExitCompletesBeforeExitedCloses`（proc） 断言 Exited() 关闭时 onExit 必须已返回。变异（把 close(exited) 挪回 onExit 之前）→ FAIL。这是本次崩溃的直接判据。 2. `TestHost_CloseUnsubscribesEventRing`（proc） 断言 Host.Close 调用了 evtCloser.Close。变异（撤掉退订）→ FAIL。 3. `TestEventRing_CloseUnsubscribesFromBus`（plugin） 端到端：订阅 → Publish 有写入 → Close → Publish 不再写入。变异 （Close 不做事）→ FAIL。 顺带给 EvtRing 加了 Written() 访问器（诊断 + 上述测试的可观察量）。 ## 验证 - 三个新测试全绿；-race 下 ./internal/plugin/... 全绿 - proc 包连跑 12 轮、internal/plugins 连跑 20 轮：SIGSEGV 0 次 - 全量 go test -count=1 ./... → 38 ok / 0 FAIL - go build ./... / go vet ./... 干净 ## 另有两个**既有** flaky（本次未动，与 C 化无关，单独记录） 排查过程中用「我的树 20 轮 vs 干净树 20 轮」对照确认了归属： - 测试间固定端口冲突（pluginmgr 9876 / remotedevice 9890 / webui 8080）： 并行或残留实例时报 bind: address already in use。干净树同样复现。 - TestRealPlugin_DeepSearchInvoke 依赖外部 SearXNG（127.0.0.1:8888）： 上游限流时（brave "too many requests"、duckduckgo/quark CAPTCHA）断言失败。 干净树同样复现。属外部依赖，不是代码缺陷。 两者都不属本次「排查崩溃」的范围，已记入 plan.md 待办。	2026-09-25 17:25:43 +08:00
JianFeeeee	5bbfcc02fb	plugin: 事件环内核侧实现（§3.6 Part 5 核心） ... 事件环（EvtRing）是子进程首次获得事件订阅能力的基础设施。 此前 case 23/24 明确返回未实现，现在经事件环真正可用。 核心设计（§3.6，实验 4 已验证 post-and-forget 加速比 2218x）： - 事件环放**独立共享段**（不与 StageContext 混放）：stage compact 会清 arena， 事件要独立于 stage 生命周期。Host 持有两块 memfd：fd 3 = StageContext， fd 4 = 事件环段，fd 5 = eventfd。 - 无锁数据结构：内核 WritePush 追加写 slot，子进程 EvtConsumer 消费。 writeSeq 原子递增（Bus.Publish 并发调用），readSeq 每订阅者独立。 - eventfd 通知：Linux 用 unix.Eventfd（计数合并，1000 token 只唤醒几次）， macOS 用 os.Pipe（阻塞模式走 netpoller，只 park goroutine，实验 1 验证 200 等待者仅 +1 OS 线程）。两者行为一致：Read 阻塞直到有新事件。 - 溢出语义：落后超 cap 时跳到最新，丢弃计数记入 dropped（消费者知道丢了）。 不静默覆盖最旧（写端直接覆盖 slot，读端靠 seq 判断跳过）。 - 事件类型编码：pubsdk.EventType 字符串 ↔ uint32 位索引（编译时映射表）， typeMask 位掩码过滤（1<<idx）。 Host 改动： - NewHost 同时创建事件环段和 eventfd（惰创建，一次分配）。 - Host 持有 evtSubscriber 接口（EvtRingSubscriber），由 Registry 注入 EventRing 实现——proc 包不依赖 internal/plugin（避免循环依赖）。 corehandler 改动： - events.subscribe（原 case 23）：子进程传事件类型列表，coreHandler 通过 evtRing 接口调用 EvtRingSubscribe，注册到 Bus 上。 事件经 EventRing 写入环后由子进程 mmap 读取。 - events.unsubscribe（原 case 24）：当前由内核统一清理（子进程 Stop 时）。 Registry 改动： - ensureProcHost 在创建 Host 后同时创建 EventRing（Bus → EvtRing → eventfd）， 并通过 Host.SetEvtSubscriber 注入给 coreHandler。 测试 3 项： - BasicWriteAndConsume：Host 创建 → EventRing 写入 → 消费者读到 - OverflowStillDelivers：写入超过 cap 后消费者仍能读到最新事件 - TypeMaskFiltering：typeMask 只订阅 tool_call，agent_output 被过滤 验证：go build ./... 通过；go test -race ./internal/plugin/... 全绿； 既有事件环测试 3/3 通过；proc 包测试未受影响。 Ref: docs/zh/架构迁移评估.md §3.6、docs/zh/plugin-migration-plan.md Part 5	2026-09-02 16:48:27 +08:00