// 使用低扰动原子快照、GDB 现场采样和语义对比来调试 DragonOS 内核中的时序问题、Heisenbug、阻塞挂起、丢唤醒和“加日志现象改变”的问题。适用于网络、VFS、调度、IPC、驱动等子系统；当用户提到任务卡住、CPU idle 但请求不返回、阻塞点偶发失效，或明确要求在线取证且不想依赖高频日志时使用。
专用于按照 docs/introduction/develop_nix.md 的流程，通过 Nix dev shell / yolo 命令启动 DragonOS，并在 QEMU nographic 串口中做启动烟雾检查或实时轮询回贴输出。当用户要求“按 develop_nix 跑 yolo”“用 nix yolo 启动 QEMU 看输出”“边跑边轮询输出”“进 guest 后检查 /proc、/sys/fs/cgroup、mount 是否正常”时使用。
分布式多智能体缺陷检测总控技能。基于输入随机化、角色化并行评审、语义桶化、加权共识与裁决复核输出高信噪比代码评审报告。用于大规模 PR、复杂逻辑变更、安全敏感改动或单智能体评审召回率不足的场景。
bug-hunter 阶段 1 技能。负责提取代码改动、执行敏感信息脱敏，并按文件/代码块生成多轮随机化输入以缓解 LLM 位置偏差。
bug-hunter 阶段 2 技能。负责将随机化后的 diff 按 persona 矩阵分发给 8 个子智能体并行评审，并收集统一 JSON 结果。
bug-hunter 阶段 3 技能。负责对多智能体原始发现做语义去重、桶化聚类与冲突识别，形成可投票的缺陷候选池。
bug-hunter 阶段 4 技能。负责对缺陷桶执行加权共识投票，筛选过阈值问题，并输出裁决级结构化评审报告。
| name | dragonos-atomic-snapshot-debug |
| description | 使用低扰动原子快照、GDB 现场采样和语义对比来调试 DragonOS 内核中的时序问题、Heisenbug、阻塞挂起、丢唤醒和“加日志现象改变”的问题。适用于网络、VFS、调度、IPC、驱动等子系统；当用户提到任务卡住、CPU idle 但请求不返回、阻塞点偶发失效，或明确要求在线取证且不想依赖高频日志时使用。 |
在不显著扰动时序的前提下，定位 DragonOS 内核中的阻塞挂起、时序敏感 bug 和事件交接异常。
核心原则：
debug!/printk。优先用于这些情况：
read()/write()、send()/recv()、poll()/epoll()、futex、completion、wait_queue 等阻塞路径偶发不返回先收集最小现场：
如果系统已经 panic，先按普通崩溃路径排查；本 skill 主要用于“系统还活着，但线程睡死/事件没继续推进”的场景。
挂住时先用 GDB 打断，确认：
idle如果两个 CPU 都 idle，通常说明：
不要一开始就加大范围过程日志。优先在真正会睡眠的点记录静态原子量。
优先放在真正会阻塞的边界上：
wait_event_* / futex / completion / schedule() 前推荐记录字段：
ACTIVEPIDTOTALTARGETEVENTSSTATEFLAGSQUEUE_LENPROGRESS_COUNTERLAST_EVENTLAST_SOURCE_STATELAST_TARGET_STATETIMER_OR_DEADLINE命名建议：
DRAGONOS_<SUBSYSTEM>_DEBUG_<FIELD> 风格DRAGONOS_VFS_DEBUG_READ_WAIT_ACTIVEnm -C 和 gdb x/gx 直接定位实现建议：
AtomicUsize / AtomicU64Ordering::RelaxedACTIVE=1ACTIVE当 wait 点已经能证明“线程睡住了”，再向下一层加计数器，而不是直接打印过程日志。
常见有效计数器类型：
enqueue/dequeue、wake/sleep、submit/completequeue_len、head/tail、depth/max_depthschedule_count、wake_count、sleep_counttimer_fire_count、next_deadlineirq_count、poll_count、rx_count、tx_count用计数器回答这些问题：
Heisenbug 排查里，一个常见误区是：
因此每次复现前都要确认：
bin/vmstate/gdb 对应的是当前实例读取命令模板见：
读取时优先关注“证据链”，不要只看单个字段。
常见判读模式：
WAIT_ACTIVE=1含义：
queue_len > 0 或 produce_count > consume_count含义：
含义：
这时应立即对比 Linux 6.6 或 DragonOS 自身的契约边界，而不是继续堆下层补丁。
最终输出不要只写最后一个修复点。应同时记录：
遇到边界层时，优先检查：