一、问题是什么
某嵌入式 Linux 智能电视平台上,一款全球视频应用通过厂商自研的对接层(基于某嵌入式 Chromium 框架)运行。设备出厂后的崩溃信息会经平台脱敏后回传到崩溃监控后台,每周以 Excel 形式导出一批。
我的工作是把这些回传上来的崩溃分类、登记、跟进------同一个 bug 归一类、追到原因、回灌修复。
听起来不复杂,但有两个性质让"两个崩溃是不是同一个"这件事变得很难判断:
- 对接层库的加载基地址不确定 ------ 不同设备、不同时刻加载,起始地址都不同,栈里的绝对地址不能直接比对
- 库被 strip 掉了可读符号 ------ 栈里没有函数名,只有
<anonymous:XXXX>这种裸地址
把两份 GDB backtrace 摆在面前:地址不同、符号没有,怎么判定它们是不是同一个 bug?
这是个看着琐碎、实际很容易出错的工作。一周回传几百条崩溃,人工肉眼比对一上午,一致性还差。必须靠算法。
二、核心观察:绝对地址不可比,但相对偏移恒定
库被加载时基地址在变,但库内部代码的相对偏移是恒定的。
也就是说,如果两个崩溃源自同一段代码,那么:
- 同一个函数里两个相邻指令的地址差 → 永远一样
- 同一调用链上两个关键栈帧之间的地址差 → 永远一样
- 一段代码相对该库基地址的偏移 → 永远一样
把"绝对地址比对"换成"相对偏移比对 ",就绕过了基址随机化。把"符号比对"换成"地址差指纹",就绕过了 strip 缺符号。
剩下的问题就是:哪两个地址值得拿来做差?
三、三阶段去重算法
我把判定逻辑做成了三阶段递进。先做便宜的、能直接归类的;再做核心的指纹比对;最后做多维度交叉验证。
阶段 1:同类异常筛选 + 已知库匹配
第一刀切粗粒度:
- 异常类型对比(信号、抛出类型、异常码)------ 不同信号(SIGSEGV vs SIGABRT)直接分开,没必要进下一阶段
- 已知库名匹配 ------ 如果崩溃帧命中已知库(系统驱动、播放器子系统、图形子系统等,这些没被 strip,符号可读),直接按库归类,不必走指纹路径
这一阶段处理掉绝大部分"明显不是同一个问题"的崩溃,把昂贵的指纹比对留给真正需要它的"匿名地址栈"。
阶段 2:栈关键点的相对地址差指纹 ⭐ 核心算法
匿名地址栈不能比绝对值,要构造指纹。
GDB backtrace 自上而下编号 #00、#01、#02...,栈顶是触发崩溃的指令,往下是调用链。经验上,#05 和 #06 这两帧的位置 在这套对接层的崩溃里非常稳定 ------ 比栈顶(经常是 libc 内的 abort/信号处理)有业务语义,比深层栈帧又不至于丢失关键路径信息。
于是我取这两帧的地址,记为 trace_5 / trace_6,定义:
distance = |trace_5_addr - trace_6_addr| (hex)这是核心指纹 ------ 同一个 bug 路径上,distance 是固定的,不管设备是谁、不管这次 Starboard 类对接层加载到哪个基地址。
对于匿名地址本身,还做了一步消除随机化:
address_flag = anonymous_addr - cobalt_base_addr把对接层加载的基址减掉,得到相对该库的偏移 ------ 即使下次重启基址变了,这个偏移依然不变。
交叉比对时还做了一件事:±2 hex 容差 。两个崩溃 distance 差 1~2,认为是同一类。这是为了容忍不同固件版本里同一段代码经编译优化后产生的微小偏移变化------如果不容差,会出现"同一个 bug,不同固件版本被分成两类"的伪分裂。
阶段 3:辅助维度交叉验证
光靠两个数字不放心 ------ 不同 bug 路径偶尔会撞同样的 distance 值。所以再叠上一组上下文维度做交叉验证:
| 维度 | 作用 |
|---|---|
| 芯片型号 | 不同芯片厂商的工具链编译结果不能混 |
| 对接层版本 | 跨大版本不能做指纹比对(代码都变了) |
| 崩溃线程 | 主线程 vs 解码线程 vs 网络线程,崩溃语义完全不同 |
| groundMode | 前台崩溃 vs 后台崩溃,触发条件不一样 |
| startIn1Min | 应用启动 1 分钟内崩溃 vs 长时间运行后崩溃,常对应"初始化/资源问题"和"运行时问题"两类 |
| hasCobalt | 崩溃时是否捕获到对接层版本号(没捕获的归一类,避免脏数据混进精确簇) |
三阶段都吻合 → 判定为同一个或同一类崩溃。
四、把判定逻辑编码成一行字符串:Crash Flag
三阶段算法输出最终要落到数据库去重和按维度汇总。我把整套判定逻辑压缩为一行字符串,作为崩溃记录的主键:
{chip}_{thread}_{lib}_{address_flag}_{distance}_{hasCobalt}
↑ ↑ ↑ ↑ ↑ ↑
芯片 线程 库匹配 基址消除偏移 地址差指纹 上下文
(阶段3) (阶段3) (阶段1) (阶段2) (阶段2) (阶段3)举例:
mt***_PlayerMain_libcobalt_4a8c_2e1c_1
mt***_PlayerMain_libcobalt_4a8c_2e1c_1 ← 主键命中,自动去重 +1
mt***_NetIO_libcurl_-_-_1 ← 库名匹配,不需要指纹
mtk_PlayerMain_libcobalt_4a8c_2e1d_1 ← distance 相差 1,±2 容差视为同类好处:
- 数据库主键即去重逻辑 ------ SQLite
INSERT OR IGNORE一句话搞定,不需要在应用层做复杂比对 - 按任一段聚合就能出报表 ------
GROUP BY chip看哪个芯片型号问题多,GROUP BY thread看哪个线程不稳定 - 人能直接读 ------
mt5895_PlayerMain_libcobalt_*一眼看出"主芯片上播放主线程在对接层里挂的那一批"
五、不是一个脚本,是一套工具
写到这里都还是算法。但实际上算法只占代码量的小头 ------ 真正吃工作量的是把这件事做成可持续使用的运营工具。
5.1 11+ 模块、4 层架构
| 层 | 模块 | 职责 |
|---|---|---|
| 入口 | main_crash.py / main_dashboard.py / main_dash2total.py / csv2excel.py |
四个入口编排不同流水线(主流程 / 与官方崩溃面板比对 / 后处理追加列 / 格式转换) |
| 读取 | read_crash.py(CrashExcelProxy) |
读 Excel、base64 解码堆栈、过滤目标应用相关崩溃、汇总统计 |
| 模型 | crash_info.py / trace.py / crash_detail.py / crashExtension.py / crash_flag.py |
单条崩溃数据模型 / 原始崩溃文本解析 / 首个崩溃栈细节(trace_5/6、lib、anonymous、LocalTime) / 扩展元数据(cobalt base、groundMode、upTime、preload、userAgent) / Crash Flag 生成 |
| 视图 | excel_view_all.py / excel_view_summary.py / excel_common.py |
详细记录 + 按类型/线程/国家/周/区域/地址标记的汇总视图 + Excel 样式工具(边框、字体、斑马纹、冻结窗格) |
| 持久 | dba/sqlite_db.py / dba/crash_db.py |
通用 SQLite 封装 + 崩溃专用去重插入/汇总查询 |
| 交叉比对 | dashboard.py |
把崩溃类型与官方崩溃面板的栈做 ±2 容差交叉比对,识别已知/未知问题 |
不是 "几个函数堆一个文件",是有明确职责边界、能被另一个程序员看一眼就理解结构的工程。
5.2 数据流
原始数据 (Excel,含 base64 编码崩溃堆栈)
↓ CrashExcelProxy.readCrash_ex()
base64 解码 → CrashInfo
↓ 过滤目标应用相关崩溃
TraceInfo → CrashDetail(首个崩溃栈)+ CrashExtension(扩展元数据)
↓ CrashFlag 生成 6 段主键
按 type/thread/country/addressFlag/week/region 汇总
↓ excel_view_*.py
crash_recorders.xlsx(多 sheet 报告)
↓ dba/crash_db.py
SQLite 数据库 → 崩溃表 → V_WeekSummary 周视图5.3 持续运营的几个关键约定
- 数据按周入库 :输入文件命名
crash_MMDD_MMDD.xlsx(如crash_0929_1002.xlsx),按周拉、按周入、按周出报告 ------ 形成稳定的运营节拍 - SQLite 周视图 :
V_WeekSummary直接 SQL 出"上周这类 crash 多少例 / 走势如何",历史数据持续累积,不是看完即弃 - py2exe 打包成 Windows exe :同事不需要装 Python 环境,双击就用 ------ 工具的工具,前提是别人能用
- 特定海外市场专项 :只处理目标市场国家(
country_areas.csv维护 country_code → region 映射,read_crash.py内置国家白名单过滤),不是全市场普查 ------ 工具的边界与业务边界对齐
六、收益
| 维度 | 收益 |
|---|---|
| 单条崩溃分析耗时 | 2 天 → 十几分钟 |
| 工作量 | 大幅压缩,从"全人力扛"变成"工具兜底人工只看疑难" |
| 判定一致性 | 不再依赖个人状态,算法判定每次结果可复现 |
| 数据资产 | 多周崩溃累积为可查询历史库,趋势可见 |
| 组织级回报 | 获公司年度创新奖 |
七、抽象到方法论
回头看这件事,有几条值得标记:
7.1 在带噪声的二进制栈上做指纹,有套路
这套思路并不孤独------现代崩溃监控工具(Sentry / Bugsnag / Crashlytics)栈指纹算法是同源思路:都是在"符号信息不全 / 地址不可比"的环境下,通过提取"相对稳定特征"做哈希式归并。
只是当时身处嵌入式现场,没参照过这些工具,是自己独立想出来并实现的。
可以把这套套路归纳为:
当绝对值不可比 时,找相对值 ;
当精确值不可得 时,找特征值 + 容差 ;
当单一维度不够 时,多维度交叉验证。
任何带噪声的指纹/去重场景都适用 ------ 不只是崩溃栈。
7.2 算法的工程含金量,藏在"把它做成可持续工具"里
如果只把算法实现成一个 Python 函数,它的价值是有限的。
把它做成:
- 有数据流的工具
- 有持久层的资产
- 有打包发布的交付方式
- 有运营节拍的使用约定
- 有按维度汇总的视图
------ 算法才会每天都在产生回报,而不是"做完就过去了"。
很多技术博客只讲算法本身,跳过工具化和运营化。但真实工作里,算法只占代码量的小头,把它做成可持续工具的部分,才是大头。
7.3 "琐碎工作"里藏着创新点
这件事最初的定性是"比较琐碎,容易出错"。如果接受这个定性,就只会在原地用更多人工去对抗琐碎。
但琐碎、容易出错、重复做 ------ 正是自动化最该出手的地方。识别这个信号,把琐碎变成算法 + 工具,就是创新点。
算法是"看到"问题,工具是"持续解决"问题。
后者比前者难,但也更值钱。