|
|
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 |
|
|
|
b71a88a471
|
chore(shm): 补齐 §13 验证项，删除统一区域遗留死代码
三件事，都是 plan.md §13 里未打勾的项：
1. §13.3「Bench: ToolInvoke 延迟对比」补测（bench_test.go）
改造后原有的 BenchmarkToolInvoke 仍走 legacy 内联 Args，已不代表生产
路径。拆成 inline / frame 两个子基准并各测两个尺寸（-count=3 取中位）：
payload inline（RPC 报文） frame（共享内存帧） 差
16 B 26.4 µs/op 48.0 µs/op +21.6 µs
32 KiB 695.6 µs/op 391.7 µs/op −303.9 µs
取舍随尺寸翻转：小 payload 多付 ~22µs 帧固定开销，大 payload 省掉整份
JSON 编解码与管道拷贝、快 44%。因为线上工具结果动辄几十 KB 且 22µs
相对 LLM 往返 2-8 秒可忽略，所以统一走帧而不按大小分叉（§13.3 第 4 条）
是对的。
2. 删除 §13.1 遗留死代码（evtring.go）
allocEvtRing 自统一共享区域之后从未被调用——旧版它单独建 memfd + eventfd，
现在只有一个 memfd，事件环只是区内的一个 segment（NewEvtRing 操作区内
切片）。留着会让人误以为事件环还有独立段。
3. 修正误导性注释（plugin.go）
仍写着旧 3-fd 布局「3=StageContext, 4=事件环, 5=通知」，与实现
（procExtraFilesForShm 只返回 memfd+evtfd）和 shmpass_unix.go 的权威
注释互相矛盾。
plan.md：§13.1/13.3/13.4/13.8 的验证项按实测打勾，并注明证据（提交号 /
测试名 / 实测数字），不留无依据的勾。
|
2026-09-10 21:18:16 +08:00 |
|
|
|
c03de9878d
|
fix(proc): EvtConsumer 生命周期——消除 host.Close 后的 SIGSEGV
预存缺陷（非本次重构引入，但会稳定复现崩溃）：
Stop() 只 close 了 stop channel，而 Run() 阻塞在 evtfd.Read 里，
根本没有机会检查 stop。调用方在 Stop 后释放 ringData（host.Close
会 munmap 整个区域），Run 一旦从 Read 恢复就会读已解除映射的内存：
**SIGSEGV，recover 捕不到**。实测 TestEventRing_OverflowStillDelivers
约 50% 概率触发。
两次尝试与结论：
1. os.File.SetReadDeadline 无效——eventfd/pipe 经 os.NewFile 包装后
**不会**注册进 Go netpoller（os.NewFile 对非 open 得到的 fd 一律按
非 pollable 处理），Read 是阻塞 syscall，SetReadDeadline 返回错误。
2. 改为 poll(2) 显式加超时（evtpoll_unix.go），消费循环每 100ms 回到
stop 检查。
新增 API 契约：
- Stop() 非阻塞，仅请求退出
- Wait() 阻塞至 Run 退出；**返回后才能释放 ringData**
- drainEvents 每条事件后检查 stop，避免慢 handler 拖延退出
其他：
- evtring_test.go 三个用例改为 defer Wait() → defer Stop()（LIFO 保证
Wait 先于 host.Close 完成）
- 溢出用例的 handler 改为非阻塞投递：写入了 8292 条事件而 channel 只
消费 1 条，阻塞投递会让 drainEvents 卡在 handler 里，Stop 无法退出
|
2026-09-10 17:56:54 +08:00 |
|
|
|
d027c964e2
|
proc: Windows 共享内存 + 事件通知适配（Part 6.2 内核侧）
补齐内核侧的 Windows 创建端，与 6.1 的插件侧打开端配对。三平台
（linux/darwin/windows）现在都能构建 internal/plugin/proc。
## Windows 走命名内核对象（无 fd 继承语义）
os/exec 的 ExtraFiles 在 Windows 实现里不被支持，故：
- shmalloc_windows.go：CreateFileMappingW（INVALID_HANDLE_VALUE + 命名 →
系统页文件支撑的匿名段，不落盘）+ MapViewOfFile
- evtfd_windows.go：CreateEventW 命名 Event 对象 + SetEvent 通知
- shmpass_windows.go：把段名/对象名经环境变量注入子进程
（HOMEAGENT_SHM_STAGE / HOMEAGENT_SHM_EVTRING / HOMEAGENT_EVT_EVENT）
名字带 PID + 递增序号：多个 homed 实例并存时不能撞名。
Event 与 eventfd 的语义差异：Event 是二元信号，多次 SetEvent 只对应一次
唤醒，不累积。不影响正确性——消费者被唤醒后按 readSeq 追 writeSeq 批量
drain，丢的是"唤醒次数"不是"事件"；事件环本身就允许溢出丢弃并让消费者
知道丢了（dropped 计数），通知面从来不是可靠投递语义。
## 传递机制抽象为 shmpass_*.go
Plugin.Start 不再直接构造 ExtraFiles 列表，改为问 Host 要：
Env: p.host.procEnvForShm() // Windows 返回段名，Unix 返回 nil
ExtraFiles: p.host.procExtraFilesForShm() // Unix 返回 fd 列表，Windows 返回 nil
平台差异被收敛到这一对函数，Plugin/coreHandler/stage 全部平台无关。
## macOS pipe 生命周期修正
原实现只返回读端 fd，写端 *os.File 无人持有 → 可能被 GC 回收 →
读端收到 EOF 而非阻塞 → 消费循环变忙转。改为 pipePair 表同时持有两端，
evtfdClose 一并关闭。
## E2E 测试跟进模板拆分
模板从单文件拆成三个（主体 + unix/windows 挂载），测试需要一并落盘，
否则编译报 attachStageShm undefined。procRuntimeTemplates 表必须与
SDK 仓 proc_runtime.go 的 procRuntimeFiles 一致。
验证：三平台 go build ./internal/plugin/... 通过（gojieba 的 cgo 依赖
导致 internal/memory 在非 linux 失败，与本次无关）；
go test -race ./internal/plugin/... 全绿，含 2 项真实模板 E2E。
Ref: docs/zh/架构迁移评估.md §9.2、docs/zh/plugin-migration-plan.md Part 6
|
2026-09-02 19:07:14 +08:00 |
|
|
|
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 |
|
