CEF 138 消息循环任务 null 解引用 (CrBrowserMain)

• 签名: Chromium Embedded Framework+0x000000000733d4c5
• 目标: Skyward (StreamGaGa/vidus 马甲) x86_64 v2028,CEF 138.0.18 (1380.0.18.0, 内部构建)
• 数量: ×7 (2026-07-23 ~ 07-27,持续发生)
• 崩溃类型: EXC_BAD_ACCESS / KERN_INVALID_ADDRESS,address = 0x28(null 指针 + 0x28 字段偏移)
• 线程: CrBrowserMain(浏览器主线程)

调用栈结构(7 份 dump 完全一致)

QCoreApplication::exec (Qt 主事件循环)
 → 主程序 QTimer 槽 (0x100d2badf → 0x100d3cd8a → 0x100cee0f0, VMP 主模块无符号)
 → CEF DoMessageLoopWork (qcef 外部消息泵集成)
 → 嵌套 macOS runloop (CF → HIToolbox → AppKit)
 → CEF 内部任务执行 (0x536ed4a → … → 0x733d4c5)
 → 对 null 对象取 +0x28 字段 → 崩溃

崩溃点及其上 15 帧全部在 CEF 内部;主程序仅以「QTimer 定时驱动

DoMessageLoopWork」方式参与,属 qcef 标准集成模式,主程序帧本身不是缺陷位置。

结论(置信度:中)

崩溃发生在 CEF 138 浏览器主线程处理嵌套消息循环任务时,某对象已为

null(疑似 browser/host 已销毁后仍有任务投递到主线程)。七份 dump

偏移完全一致 → 单一代码路径,大概率与页面/浏览器销毁时序有关。

无法进一步定位的原因:本地 CEF Breakpad 符号库只有 CEF 142

(debug_id 4C4C44C2…),而 v2028 使用内部构建的 CEF 138

(debug_id 4C4C447455553144A19E718FD000B3410)。Spotify 官方符号

不适用(内部构建为 lld 伪 UUID)。

行动项

1. 向构建组索取内部 cef_mac_138 (x86_64) 的 PDB/Release dSYM

(同 cef_mac_142 的归档方式),然后 build_cef_symbols.sh 重建

symbols/cef/x86_64/ 并 run.py --offline 重符号化,即可还原

函数级调用栈,再判断是 CEF 上游 bug 还是 qcef 集成(如

OnBeforeClose 后未停 DoMessageLoopWork 定时器)问题。

2. 符号到位前不具备 MR 条件;不建 issue 到 qcef(证据不足)。

观察建议

若 v2029+ 换用 CEF 142,可观察该签名是否消失(CEF 版本相关)。