Xxiuda3411fix: Connector支持AggregateId
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
fix: Connector支持AggregateId | 1 天前 | |
fix(hwdiscovery): 修复 position 卸载生命周期与 device_loader 异步 drain 竞争 一、卸载 position 生命周期 - stop_direct_service_objects 提为 public 并在 remove_single_position 显式调用： remove_device(position) 仅在无 unit_info 时隐式 stop，有 unit_info 但拓扑层无设备 对象的 position（CSR1 hwdiscovery 加载路径常态）会在 "device object not found" 处 早退，驱动 stop 整个丢失，需由卸载方在注销对象前显式 stop（幂等，重复调用无副作用）。 - stop_direct_service_objects 增加归属过滤：只停本 position 拥有的对象，跨 position 共享对象（因同名复用被 save_device_object 存到本 position 名下）由其属主卸载时处理； 否则对象仍注册在属主 position 上却再无路径启动它，属主周期采集会静默失活，且用本 position 的 FormatVersion 对属主不同的对象做 static_cast 会类型错配。 - remove_single_position 统一归还父对象强引用（set_parent(nullptr)）：unregister_* 只摘 对象表并置空 service/owner/group，不解除父对象 children 持有的强引用，对象永不析构， 其析构承担的驱动侧清理（Scheduler 任务、合并组、依赖注册表）全部丢失，形成持续访问 已注销远端对象的僵尸对象。归还动作放在全部 bookkeeping 之后，与 device_topo 范式一致。 - 服务解析改用 noexcept 的 application::get()，解析不到时回退到对象自身注册的 service： application::instance() 在无 mcapp application 的进程（单测、非 mcapp 宿主）中 MC_ASSERT 直接抛异常，会把异常从卸载路径整体抛出、中断后续清理；静默跳过则重新制造 僵尸对象。 二、device_loader 异步 drain 与单例销毁的竞争 - drain 任务 post 到 device_topo 的 lifecycle strand 异步执行，而 clear() 只把在途 load 标记 failed（仅防其提交），不等它退出。测试 TearDown 在 clear() 后立刻 object_group_data::reset_for_test()（即 delete 单例），在途的 execute_reserved_load 随即在已释放内存上继续访问 topology —— 堆块未被复用时读到计数已归零的 dict， 抛 "attempt to add reference to a destroyed object" 后 terminate；被复用时 SIGSEGV。 这是崩溃点随机漂移、两种信号交替出现的原因（修复前实测约 12% 复现率）。 - 新增 m_drain_tasks_inflight：投递时与 post 在同一次持锁内递增，任务真正退出时 RAII 递减（覆盖 drain_pending_loads 抛异常与 post 失败路径）；clear() 改 unique_lock， 清完内部状态后等待该计数归零（10s 兜底，strand 线程自调用时跳过），返回即代表异步 drain 已静止，调用方可在其后安全销毁单例。先清后等，使 drain 下一轮取不到请求即 收敛，不必等它跑完即将被丢弃的加载。 - drain 任务体抽为 run_pending_drain，并把 try/catch 收口到任务体内：驱动回调异常虽已 由 execute_reserved_load 内部兜住（否则同样会残留标志），但取请求、置 phase 等簿记 步骤抛异常时 m_pending_draining 仍会残留 true，后续 schedule_pending_drain 全部提前 返回、就绪请求静默停摆；异常退出时经 abort_pending_drain 复位标志。复位放在任务体内 而非 drain_scope 析构：任务退出前队列可能已清空并置 false，新请求此时可再投递一个 drain 任务，析构里的无条件复位会误清后来者的标志、造成重复投递。 三、检视意见处理（AI 检视 + 人工检视报告） - 运行时直连服务对象注销 pass 增加跨 position 归属校验，与 stop pass、for_each pass 语义一致。运行时表与 save_device_object 成对写入，其对象在 create_direct_service_devices 创建时已 set_position(position)，正常路径下必然等于本 position；该校验用于防止后续写入方把跨 position 共享对象登记进本表后，被按 path 误注销属主仍在使用的对象。 - remove_single_position 依仓库 .cursorrules（函数不超过 50 行）拆分为 unregister_runtime_direct_service_objects / unregister_legacy_device_objects / release_device_object_parents / cleanup_position_registries 四个私有辅助函数，注释随代码 搬迁，主干只保留 teardown 顺序编排；运行时注销 pass 内的服务解析与单对象注销再抽成 文件内 resolve_runtime_object_service / unregister_one_runtime_object 两个小函数， 被点名的两个函数由 60/67 行降至 46/39 行（.cursorrules:24 为 50 行上限）。 - 跨 position 共享对象回归用例补齐断言：原用例只断言对象存活，而"注销后仍被父对象 强引用"的错误实现同样能满足该断言，无法证明归属过滤生效；现补 is_registered()、 get_position() 仍为属主 9999、父引用仍在三项断言。 - clear() 复位 m_pending_draining：等待超时（drain 被驱动回调长时间占用）路径下若残留 true，后续 AddDevice 的 schedule_pending_drain 会因守卫提前 return，已就绪请求迟迟不 被 drain。同时把等待保证的边界写进注释：只覆盖异步 drain 任务，同步路径 （AddDevice 调用栈内直接执行 execute_reserved_load）不计入计数；strand 线程自调用 跳过等待的分支补 dlog，保证该路径可观测。 - manager.h 注释笔误修正：Scanner/Accessor/Scanner -> Connector/Accessor/Scanner。 - 第三轮 AI 检视三条：drain 任务异常退出残留 m_pending_draining —— 成立，已按上述方式修复； 按 path 注销的运行时对象未显式收进 releasing（父引用归还依赖"成对写入"）—— 评估后不修改， 运行时表 ⊆ device_objects 表由 device_loader 成对写入的位置保证（两次写表无条件紧邻、中间 无分支与提前返回），legacy pass 必然收集；唯一可观测差异是空 position 场景（见上，不可达）； 注销失败对象仍被归还父引用 —— 评估后不修改，注销失败说明服务仍持强引用，set_parent(nullptr) 此时只 detach 不析构，而"位置已卸载"的目标态就是 detach，按 is_registered() 过滤反而会把 对象永久留在父树里，正是本 PR 要消灭的僵尸对象。 - 第四轮 AI 检视：clear() 注释"返回即代表可安全销毁单例"的措辞未覆盖引擎 on_unregister 的 异步延迟释放任务（由引擎全局 work executor 执行，不计入 m_drain_tasks_inflight）——成立， 但属保证边界的表述问题：要 clear() 排空引擎全局队列没有公开 API，改为在声明与实现注释中 写明该保证只覆盖本 loader 的异步 drain 任务，调用方销毁单例前需自行确认这类钩子已完成。 四、版本与变更记录 - mds/service.json 组件版本号 1.2.135 -> 1.2.136，CHANGELOG 新增 [1.2.136] - 2026-09-18 条目。 验证：hwdiscovery_test 通过 meson 规范跑法连续 39 轮全绿（含三轮检视意见处理后的 15 轮）， common_test / devmon_test / devmon_device_runtime_test 各 2 轮全绿； 修复前实测约 12% 崩溃率，修复后用临时探针确认 clear() 每轮都实际等到 1~2 个在途 drain 任务。 Co-Authored-By: Claude Code <noreply@anthropic.com> AI-Agent: Claude Code AI-Model: DeepSeek-V4-Flash AI-Context: 定位并修复 hwdiscovery_test 随机崩溃（device_loader 在途 drain 任务与 object_group_data 单例销毁的竞争），复核 position 卸载生命周期改动，处理 AI/人工检视意见；同步组件版本号与 CHANGELOG Signed-off-by: leessential <lishengxiao@huawei.com> Change-Id: Iabdebb3d9010eda92603fb1dc38472a0ad0b71c7 | 1 个月前 |