长时间 AC，概率性出现板卡已加载，但传感器未注册

交流互助区
1

问题描述

长时间 AC，概率性出现板卡已加载，但传感器未注册，概率约 5%

问题现象：AC 起来后，自动化脚本检查发现 PCIe/OCP 相关传感器未出现，消失的是这些传感器：

{BAF7CCCD-857F-4183-85A2-86E52764FF27}
{BAF7CCCD-857F-4183-85A2-86E52764FF27}937×303 25.7 KB

问题时间线：

19:55 做 AC：

2026-02-25 19:55:51 CLI,Administrator@192.168.109.48:50888,fructrl,Set FRU0 to ACCycle successfully

20:01 时卡的 sr 已加载：

2026-02-25 20:01:17.712144 hwdiscovery NOTICE: hwcomponent.lua(313): [self-discovery] name: Connector_PCIE_SLOT2_01010103, position: 0101010302, current: 1, previous: 0,uptime: 269 s
2026-02-25 20:01:17.820435 hwdiscovery NOTICE: init.lua(201): position: 0101010302, get csr data from /opt/bmc/sr/14140130_100010e2_10004010.sr, format version: 3.00, data version: 3.00
2026-02-25 20:01:17.829969 hwdiscovery NOTICE: hwcomponent.lua(209): position: 0101010302, load sr data successfully, uptime: 269 s, cost: 20ms
2026-02-25 20:01:17.837994 hwdiscovery NOTICE: hwcomponent.lua(230): position: 0101010302, start to process sr data, source: /opt/bmc/sr/14140130_100010e2_10004010.sr, format version: 3.00, data version: 3.00, uptime: 269 s
2026-02-25 20:01:17.970283 hwdiscovery NOTICE: hwcomponent.lua(313): [self-discovery] name: Connector_PCIE_SLOT3_01010103, position: 0101010303, current: 1, previous: 0,uptime: 269 s
2026-02-25 20:01:18.049693 storage NOTICE: mctp_service.lua(94): [Storage] mctp prepare finished. bmc_eid = 12 bmc_phy = 768 state = true
2026-02-25 20:01:18.093276 hwdiscovery NOTICE: sdr.lua(76): position: 0101010302, get objects, count: 39
2026-02-25 20:01:18.107033 maca NOTICE: init.lua(531): bmc.kepler.bios unlocked ForceResetLocked status
2026-02-25 20:01:18.126559 hwdiscovery NOTICE: init.lua(201): position: 0101010303, get csr data from /opt/bmc/sr/14140130_808657b0_80860002.sr, format version: 3.00, data version: 3.00
2026-02-25 20:01:18.128557 hwdiscovery NOTICE: hwcomponent.lua(209): position: 0101010303, load sr data successfully, uptime: 270 s, cost: 10ms
2026-02-25 20:01:18.133372 hwdiscovery NOTICE: hwcomponent.lua(230): position: 0101010303, start to process sr data, source: /opt/bmc/sr/14140130_808657b0_80860002.sr, format version: 3.00, data version: 3.00, uptime: 270 s
2026-02-25 20:01:18.181420 hwdiscovery NOTICE: hwcomponent.lua(313): [self-discovery] name: Connector_OCP_1_0101, position: , current: 1, previous: 0,uptime: 270 s
2026-02-25 20:01:18.219446 hwdiscovery NOTICE: parser_work.lua(76): position: 0101010302, process sr data successfully, uptime: 270 s, cost: 350ms
2026-02-25 20:01:18.308729 hwdiscovery NOTICE: init.lua(201): position: , get csr data from /opt/bmc/sr/14220247_15b3101f_1f242011.sr, format version: 3.00, data version: 3.00
2026-02-25 20:01:18.315986 hwdiscovery NOTICE: hwcomponent.lua(209): position: 010107, load sr data successfully, uptime: 270 s, cost: 20ms
2026-02-25 20:01:18.318517 hwdiscovery NOTICE: hwcomponent.lua(230): position: 010107, start to process sr data, source: /opt/bmc/sr/14220247_15b3101f_1f242011.sr, format version: 3.00, data version: 3.00, uptime: 270 s
2026-02-25 20:01:18.337640 hwdiscovery NOTICE: hwcomponent.lua(313): [self-discovery] name: Connector_OCP_2_0101, position: , current: 1, previous: 0,uptime: 270 s
2026-02-25 20:01:18.466059 hwdiscovery NOTICE: sdr.lua(76): position: 0101010303, get objects, count: 26
2026-02-25 20:01:18.480409 hwdiscovery NOTICE: init.lua(201): position: , get csr data from /opt/bmc/sr/14220247_14e416d7_1f242013.sr, format version: 3.00, data version: 3.00
2026-02-25 20:01:18.499224 hwdiscovery NOTICE: hwcomponent.lua(209): position: 010108, load sr data successfully, uptime: 270 s, cost: 30ms
2026-02-25 20:01:18.508022 hwdiscovery NOTICE: hwcomponent.lua(230): position: 010108, start to process sr data, source: /opt/bmc/sr/14220247_14e416d7_1f242013.sr, format version: 3.00, data version: 3.00, uptime: 270 s
2026-02-25 20:01:18.529628 hwdiscovery NOTICE: parser_work.lua(76): position: 0101010303, process sr data successfully, uptime: 270 s, cost: 200ms

sensor 模块此时也接收到了框架的对象分发：

2026-02-25 20:01:21.336397 sensor NOTICE: object_manage.lua(332): add objects callback, path: /bmc/kepler/ObjectGroup/0101010302, life cycle id: 1, count: 7, took 1060ms, uptime: 273 s
2026-02-25 20:01:21.344539 sensor NOTICE: object_manage.lua(342): add objects completely, path: /bmc/kepler/ObjectGroup/0101010302, life cycle id: 1, took 0ms, uptime: 273 s
2026-02-25 20:01:21.373723 sensor NOTICE: object_manage.lua(312): start to add objects, path: /bmc/kepler/ObjectGroup/0101010303, life cycle id: 1, count: 2, uptime: 273 s

2026-02-25 20:01:21.763484 sensor NOTICE: object_manage.lua(332): add objects callback, path: /bmc/kepler/ObjectGroup/0101010303, life cycle id: 1, count: 2, took 390ms, uptime: 273 s
2026-02-25 20:01:21.770718 sensor NOTICE: object_manage.lua(342): add objects completely, path: /bmc/kepler/ObjectGroup/0101010303, life cycle id: 1, took 0ms, uptime: 273 s
2026-02-25 20:01:21.841223 sensor NOTICE: object_manage.lua(312): start to add objects, path: /bmc/kepler/ObjectGroup/010107, life cycle id: 1, count: 3, uptime: 273 s

2026-02-25 20:01:22.366241 sensor NOTICE: object_manage.lua(332): add objects callback, path: /bmc/kepler/ObjectGroup/010107, life cycle id: 1, count: 3, took 530ms, uptime: 274 s
2026-02-25 20:01:22.367582 sensor NOTICE: object_manage.lua(342): add objects completely, path: /bmc/kepler/ObjectGroup/010107, life cycle id: 1, took 0ms, uptime: 274 s
2026-02-25 20:01:22.395031 sensor NOTICE: object_manage.lua(312): start to add objects, path: /bmc/kepler/ObjectGroup/010108, life cycle id: 1, count: 3, uptime: 274 s

但是，在 sensor.log 里这段时间却没有看到任何传感器注册，只能看到相关卡的 fru 注册了，fru 和卡都是在同一份 sr 上的，理论上 fru 注册了传感器肯定也得注册，但是却没有：

[2026-02-25 20:00:15] discrete sdr DiscreteSensor_PwrCapStatus_01010A of host 0 is registered.
[2026-02-25 20:00:15] discrete event [DiscreteEvent_PSRedundancy_01010A] is registered
[2026-02-25 20:00:15] discrete event [DiscreteEvent_PwrCapFailed_01010A] is registered
[2026-02-25 20:00:16] Entity [Entity_Fan_01010305] of host 0 is registered
[2026-02-25 20:00:16] sensor ThresholdSensor_FanRspeed_01010305 of host 0 is registered, number is 152.
[2026-02-25 20:00:16] threshold sdr ThresholdSensor_FanRspeed_01010305 of host 0 is registered.
[2026-02-25 20:01:23] fru sdr XC385(9) of host 0 is registered by id.
[2026-02-25 20:01:23] fru sdr XC386(7) of host 0 is registered by id.
[2026-02-25 20:09:39] fru sdr ExpBoard1(1) of host 0 is registered by obj.
[2026-02-25 20:09:41] bmc global enables[RecvMsgIntrptEnabled] = 1
[2026-02-25 20:09:41] bmc global enables[EvtMsgBufFullIntrptEnabled] = 1
[2026-02-25 20:09:41] bmc global enables[EvtMsgBufEnabled] = 1
[2026-02-25 20:09:41] bmc global enables[SELEnabled] = 1

正常场景下，是有这种打印的，异常场景下却没有：

[2026-02-25 20:12:52] Entity [Entity_RaidCard_0101010302] of host 0 is registered
[2026-02-25 20:12:52] sensor ThresholdSensor_PCIeBBUTemp_0101010302 of host 0 is registered, number is 153.
[2026-02-25 20:12:52] threshold sdr ThresholdSensor_PCIeBBUTemp_0101010302 of host 0 is registered.
[2026-02-25 20:12:55] fru sdr XC385(9) of host 0 is registered by id.
[2026-02-25 20:12:55] sensor ThresholdSensor_RaidCardTemp_0101010302 of host 0 is registered, number is 154.
[2026-02-25 20:12:55] threshold sdr ThresholdSensor_RaidCardTemp_0101010302 of host 0 is registered.
[2026-02-25 20:12:55] sensor DiscreteSensor_BBUStatus_0101010302 of host 0 is registered, number is 155.
[2026-02-25 20:12:55] discrete sdr DiscreteSensor_BBUStatus_0101010302 of host 0 is registered.
[2026-02-25 20:12:56] fru sdr XC386(7) of host 0 is registered by id.
[2026-02-25 20:12:56] discrete event [DiscreteEvent_BBUStatus_0_0101010302] is registered
[2026-02-25 20:12:56] discrete event [DiscreteEvent_BBUStatus_2_0101010302] is registered
[2026-02-25 20:12:56] discrete event [DiscreteEvent_BBUStatus_1_0101010302] is registered
[2026-02-25 20:12:57] Entity [Entity_PCIeCard_0101010303] of host 0 is registered
[2026-02-25 20:12:57] sensor ThresholdSensor_Temp_0101010303 of host 0 is registered, number is 156.
[2026-02-25 20:12:57] threshold sdr ThresholdSensor_Temp_0101010303 of host 0 is registered.
[2026-02-25 20:12:58] Entity [Entity_OCPCard_010108] of host 0 is registered
[2026-02-25 20:12:58] sensor ThresholdSensor_OCPTemp_010108 of host 0 is registered, number is 157.
[2026-02-25 20:12:58] threshold sdr ThresholdSensor_OCPTemp_010108 of host 0 is registered.
[2026-02-25 20:12:58] sensor ThresholdSensor_OpticalModuleTemp_010108 of host 0 is registered, number is 158.
[2026-02-25 20:12:58] threshold sdr ThresholdSensor_OpticalModuleTemp_010108 of host 0 is registered.
[2026-02-25 20:12:59] Entity [Entity_OCPCard_010107] of host 0 is registered
[2026-02-25 20:12:59] sensor ThresholdSensor_OCPTemp_010107 of host 0 is registered, number is 159.
[2026-02-25 20:12:59] threshold sdr ThresholdSensor_OCPTemp_010107 of host 0 is registered.
[2026-02-25 20:13:00] sensor ThresholdSensor_OpticalModuleTemp_010107 of host 0 is registered, number is 160.
[2026-02-25 20:13:00] threshold sdr ThresholdSensor_OpticalModuleTemp_010107 of host 0 is registered.

怀疑存在某种概率性时序问题，sensor 模块在这段时间也没有明显报错

需要注意的是：日志是在脚本自动恢复环境后收集的

这是产生问题的那次 AC：

2026-02-25 19:55:51 CLI,Administrator@192.168.109.48:50888,fructrl,Set FRU0 to ACCycle successfully

这是恢复的 AC，这次 AC 后传感器都是正常加载的：

2026-02-25 20:07:17 CLI,Administrator@192.168.109.48:52192,fructrl,Set FRU0 to ACCycle successfully

日志已传递

环境信息

社区 1230 基线版本

2

答案内容由AI生成，仅供参考：
:white_check_mark: 总结

项目 内容
问题性质 概率性、时序敏感型注册失败
触发条件 长时间 AC 循环，约 5% 概率复现
直接表现 板卡加载成功，但传感器未出现在 SDR
根本原因 加载-卸载-再加载循环 + 对象分发失败 + IPMB 不稳定
解决方案 1. 优化防抖机制
2. 增强生命周期管理
3. 添加注册重试与日志增强

建议结合下一次复现时开启 compute、libmgmt_protocol 等组件的 debug 日志，并执行带内命令（如 npu-smi）验证设备端状态，以进一步闭环分析。

点击此处查看详细分析解答

长时间 AC 后板卡已加载但传感器未注册问题分析报告

问题概述

在长时间进行 AC 循环测试时，系统出现概率性（约 5%）板卡 SR 文件成功加载，但其对应的传感器未注册的问题。尽管日志显示 PCIe/OCP 板卡的 SR 配置文件已正确加载，且 sensor 模块接收到了对象分发请求，但 sensor.log 中并未记录相关传感器的注册日志，仅看到 FRU 对象注册成功。

:receipt: 问题现象

  • 现象描述：AC 上电后自动化脚本检测发现部分 PCIe 和 OCP 卡的温度传感器缺失。
  • 典型表现：
    • sensor.info.txt 中存在如下条目：
      85 0x8f Disk BP1 Temp 27.000 degrees C ok na na na
89 0x9e OCP2 OP Temp 45.000 degrees C ok na na 105.00
91 0xa0 OCP1 OP Temp na degrees C na na na na
      其中 OCP1 OP Temp 显示为 na，表明读值异常或传感器未生效。
  • 关键矛盾点：
    • SR 文件已成功加载（见 hwdiscovery 日志）。
    • sensor 模块已接收并处理了对象分发（object_manage.lua 记录添加成功）。
    • 但 sensor.log 没有传感器注册日志（如 xxx is registered），仅有 FRU 注册记录。

:stopwatch: 时间线与关键日志分析

时间 事件
19:55 执行 AC 操作：Set FRU0 to ACCycle successfully
20:01:17 开始加载 PCIe/OCP 板卡 SR 文件（路径 /opt/bmc/sr/...）
20:01:18 SR 加载成功，开始处理配置数据
20:01:21 sensor 模块接收对象分发并完成添加（耗时 390~1060ms）
20:01:23 sensor.log 中仅记录 FRU 注册，无传感器注册日志

:white_check_mark: 成功路径证据（板卡加载成功）

hwdiscovery NOTICE: position: 0101010302, get csr data from /opt/bmc/sr/14140130_100010e2_10004010.sr, format version: 3.00, data version: 3.00
hwdiscovery NOTICE: load sr data successfully, cost: 20ms
hwdiscovery NOTICE: start to process sr data
sensor NOTICE: add objects callback, path: /bmc/kepler/ObjectGroup/0101010302, count: 7
sensor NOTICE: add objects completely

:cross_mark: 缺失路径证据（传感器未注册）

[2026-02-25 20:01:23] fru sdr XC385(9) of host 0 is registered by id.
[2026-02-25 20:01:23] fru sdr XC386(7) of host 0 is registered by id.
→ 但无 threshold/discrete sensor 注册日志

:magnifying_glass_tilted_left: 结论：系统完成了“加载 → 解析 → 分发”流程，但 sensor 组件未能将对象注册到 SDR（Sensor Data Record）数据库中。

:magnifying_glass_tilted_left: 根本原因分析

结合知识图谱和日志，本问题可归结为 “动态传感器分配过程中的时序竞争与对象生命周期管理缺陷”。

1. AC 启动阶段对象初始化存在竞争条件

现象依据：

  • AC 启动（AC启动）期间，FRU 控制模块 (fructrl) 负责初始化关键对象（如 ACCycle, PowerAction, ForceReset）。
  • 来自 Document Chunks 的日志显示：
    Objects [ACCycle] in objs_bef_init distribute failed.
Objects [ForceReset] in objs_bef_init distribute failed.
    这表明 fructrl 在初始化阶段存在对象分发失败的情况。

影响：

  • sensor 模块依赖其他模块提供的对象引用（如电源状态、位置信号）来完成传感器注册。
  • 若依赖对象尚未准备就绪，即使接收到配置信息，也可能跳过或延迟注册。

2. 加载后卸载再加载过程导致类定义冲突（时序敏感）

知识库关联：

  • 实体：加载后卸载再加载过程
  • 描述：“A rapid cycle of loading and unloading leads to duplicate class definitions and failure in temperature monitoring.”

结合日志分析：

  • AC 操作可能导致 PCIe 卡在位状态多次跳变（从 0 → 1 → 0 → 1），触发 hwdiscovery 的“自发现”机制反复执行。
  • 日志中出现连续多次 [self-discovery] name: Connector_PCIE_SLOT... 的记录，表明存在“快速加载-卸载-再加载”循环。
  • 若卸载未完成即重新加载，可能造成：
    • 旧对象未完全销毁；
    • 新对象尝试注册相同 Class 或 UUID；
    • kepler.class.ClassDuplicateDefined 错误（见 DC#5）；
    • 导致传感器对象创建失败。

3. 传感器注册依赖 IPMB 通信，AC 时链路不稳定

知识库支持：

  • CPU Temperature 描述中明确指出：

    “…fail to be obtained due to IPMB message transmission failures.”

  • 同理适用于 OCP/PCIe 卡传感器。

推断：

  • 在 AC 上电初期，BMC 与远端设备（如 OCP 卡、RAID 卡）之间的 IPMB/MCTP 链路可能尚未稳定。
  • sensor 模块在尝试注册传感器时会验证通信可达性，若链路未通，可能静默跳过注册或标记为“Degraded”而非直接报错。

4. 动态传感器分配机制缺乏状态追踪

知识库支持：

  • 实体：Dynamic Sensor Allocation

    “requires correlation with sensor.log or app.log to identify the affected sensor.”

  • 表明传感器 ID 在每次启动时动态分配，无法静态绑定。

问题：

  • 当 AC 循环频繁发生时，同一物理卡的传感器可能被赋予不同的虚拟 ID。
  • 若日志未记录完整生命周期事件（创建/销毁/错误），则难以追踪“为何某次未注册”。

:puzzle_piece: 综合结论

因素 是否相关 说明
:white_check_mark: 对象分发失败（fructrl 初始化异常） 是 ACCycle、ForceReset 分发失败，影响全局控制流
:white_check_mark: 快速加载-卸载-再加载 是 导致对象重复定义、生命周期混乱
:white_check_mark: IPMB 通信不稳定 是 AC 初期链路未稳，导致传感器注册条件不满足
:white_check_mark: 动态分配无回溯机制 是 缺乏注册失败后的重试或告警机制

:bullseye: 根本原因总结：
在 AC 启动过程中，由于 fructrl 初始化异常与 PCIe/OCP 卡在位状态抖动引发的“快速加载-卸载-再加载”过程，导致传感器对象在注册阶段遭遇类重复定义、通信链路不稳定等问题，最终因时序竞争而导致传感器注册失败。

:white_check_mark: 解决建议与规避措施

1. 优化在位信号防抖处理（关键）

  • 参考 DC#5 中 DPU 卡问题经验：

    “AC启动过程中，DPU卡在位默认配置成了在位…造成卡会出现误加载后卸载再加载现象”

  • 建议：
    • 增加在位信号采样的防抖时间窗口（建议 ≥200ms）；
    • 确保只有在硬件电平稳定后才触发加载动作；
    • 避免“瞬时高 → 低 → 高”导致重复加载。

2. 增强对象生命周期管理

  • 在 sensor 模块中增加：
    • 注册前检查是否已存在相同 ID 的对象；
    • 支持优雅卸载（等待读写完成后再释放）；
    • 注册失败时输出明确错误日志（如 error: sensor registration failed for OCP1_OP_Temp）。

3. 增加传感器注册重试机制

  • 若首次注册失败（如因 IPMB 未通），设置定时器在 5~10 秒后自动重试。
  • 可结合 Dynamic Sensor Allocation 特性，动态关联后续加载的传感器。

4. 完善日志跟踪能力

  • 在 sensor 模块启用 Debug 级别日志：
    log_debug("Attempting to register sensor %s, path=%s", name, path)
  • 使用 one-click collection 收集 sensor.log, app.log, hw_stream.log 联合分析。

5. 固化关键组件加载顺序

  • 强制 ACCycle, PowerAction 等基础对象优先于 hwdiscovery 加载；
  • 若 fructrl 中 ACCycle 加载失败，应终止后续流程并告警，避免继续加载板卡。

:pushpin: 附加说明：关于 32767 的含义（参考相关案例）

虽然本次问题不涉及数值异常，但日志中常出现的 32767 值也值得说明：

值 含义 来源
32767 BMC 成功收到数据包，但 NPU 卡未提供有效温度值 32767 is a special numeric value...
32768 BMC 未能从卡侧获取任何温度数据 32768为bmc从卡侧获取温度失败

→ 可辅助判断是“通信失败”还是“卡端无值”。

:white_check_mark: 总结

项目 内容
问题性质 概率性、时序敏感型注册失败
触发条件 长时间 AC 循环，约 5% 概率复现
直接表现 板卡加载成功，但传感器未出现在 SDR
根本原因 加载-卸载-再加载循环 + 对象分发失败 + IPMB 不稳定
解决方案 1. 优化防抖机制
2. 增强生命周期管理
3. 添加注册重试与日志增强

建议结合下一次复现时开启 compute、libmgmt_protocol 等组件的 debug 日志，并执行带内命令（如 npu-smi）验证设备端状态，以进一步闭环分析。

3

日志传递哪了 转发一下吧

4

有没看 问题传感器 的position是多少

5

传感器的 position 是 0101010302、0101010303、010108、010107

这四张卡都同时出现了卡已加载，但传感器未注册的情况

6

麻烦再看一下 sensor.log里 这4个position的是一个都没有注册吗（所有的，不止包含你上面的对象）

8

是的，那一次 AC 启动，这四个 position 的传感器/Entity/离散事件一个都没有注册

不过 fru sdr 倒是注册了

[2026-02-25 20:01:23] fru sdr XC385(9) of host 0 is registered by id.
[2026-02-25 20:01:23] fru sdr XC386(7) of host 0 is registered by id.

这两个 fru sdr 倒是属于 position 010107 和 010108 的

9

日志我找他要一下 你再帮看一眼 libmc 版本

10

libmc4lua/1.100.73@openubmc/stable

11

麻烦在app日志里过滤下get_rpc_log_threshold

查看是否有报错

疑似已解决问题

12

Hello! 我这边出现了类似的问题，内存传感器加载完成上树，但DiscreteEvent_DIMMxxxxx未加载，可以帮忙分析一下什么原因吗？

版本也是1230基线版本

日志见附件，请将txt格式删除后解压

S950X00_2102315RYU10S1100021_20260303-0941_2.7z.001.txt (9 MB)

S950X00_2102315RYU10S1100021_20260303-0941_2.7z.002.txt (4.3 MB)

13

搜索无相关打印

{4AE60407-6465-47FE-A6A6-09903228B47D}
{4AE60407-6465-47FE-A6A6-09903228B47D}561×440 9.34 KB

14

OK

那等看下日志

15

这里看起来是有一个时序问题

检视 src/lualib/sensor_service.lua 中的 cache 相关代码，我觉得这代码有大问题，你看 on_add_object_complete 的部分，它只在 not cache_task_alive 的时候启动 task，但 task 里又是一个 60 次遍历的循环；如果某次 on_add_object_complete 的时候，上次的 task 并没有结束，并且上次的 task 恰好在最后一次循环的 sleep 过程中，那么岂不是新任务不会创建，老任务也将要退出，于是这个 position 就不会调用相关 register_cache 函数，造成传感器丢失吗？

你的分析完全正确！这确实是一个严重的并发问题。让我详细说明一下这个 bug：

问题分析

当前代码逻辑

  1. on_add_object_complete 回调（第 415-420 行）：
mdb_manager.on_add_object_complete(self.bus, function (position)
    if not cache_task_alive then
        skynet.fork_once(self.register_cache_objs_task, self)
    end
    unregistered_positions[position] = true
end)
  1. register_cache_objs_task 任务（第 513-538 行）：
function sensor_service:register_cache_objs_task()
    local ticks = 0
    if not cache_task_alive then
        cache_task_alive = true
    end
    local position
    while ticks < 60 do  -- 连续 60次等待 无待注册的对象则认为所有对象已注册完成
        position, _ = next(unregistered_positions)
        if not position then
            ticks = ticks + 1
            goto continue
        end
        
        register_cache_entities(self, position)
        register_cache_sensors(self, position)
        register_cache_discrete_events(self, position)
        unregistered_positions[position] = nil
        
        ::continue::
        skynet.sleep(100)
    end
    if cache_task_alive then
        cache_task_alive = false
    end
end

Bug 场景重现

假设时间线如下：

  1. T0: on_add_object_complete(position1) 被调用

    • cache_task_alive = false，启动 Task1
    • unregistered_positions = {position1 = true}
    • Task1 开始运行，cache_task_alive = true

  2. T1: Task1 执行到第 59 次循环（ticks = 59）

    • 此时 unregistered_positions 为空
    • ticks 增加到 60
    • 执行 skynet.sleep(100)，Task1 进入睡眠

  3. T2: 在 Task1 睡眠期间，on_add_object_complete(position2) 被调用

    • cache_task_alive = true（Task1 还在运行）
    • 不会启动新任务！
    • unregistered_positions = {position2 = true}

  4. T3: Task1 从睡眠中醒来

    • 检查 ticks < 60？false（ticks = 60）
    • 退出循环
    • cache_task_alive = false

  5. 结果：position2 永远不会被注册，传感器丢失！

根本原因

设计上存在一个竞态条件：

  • on_add_object_complete 只在 cache_task_alive = false 时启动新任务
  • 但 register_cache_objs_task 使用固定 60 次循环，不管是否有新的 position 加入
  • 当任务即将结束时（ticks 接近 60），新加入的 position 会被遗漏
16

传感器注册阶段处理已优化，见 优化传感器对象注册性能