一、问题是什么

某嵌入式 Linux 智能电视平台上,一款全球视频应用通过厂商自研的对接层(基于某嵌入式 Chromium 框架)运行。设备出厂后的崩溃信息会经平台脱敏后回传到崩溃监控后台,每周以 Excel 形式导出一批。

我的工作是把这些回传上来的崩溃分类、登记、跟进——同一个 bug 归一类、追到原因、回灌修复。

听起来不复杂,但有两个性质让"两个崩溃是不是同一个"这件事变得很难判断:

1. 对接层库的加载基地址不确定 —— 不同设备、不同时刻加载,起始地址都不同,栈里的绝对地址不能直接比对
2. 库被 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 值。所以再叠上一组上下文维度做交叉验证:

三阶段都吻合 → 判定为同一个或同一类崩溃。

四、把判定逻辑编码成一行字符串: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 层架构

不是 "几个函数堆一个文件",是有明确职责边界、能被另一个程序员看一眼就理解结构的工程。

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 内置国家白名单过滤),不是全市场普查 —— 工具的边界与业务边界对齐

六、收益

七、抽象到方法论

回头看这件事,有几条值得标记:

7.1 在带噪声的二进制栈上做指纹,有套路

这套思路并不孤独——现代崩溃监控工具(Sentry / Bugsnag / Crashlytics)栈指纹算法是同源思路:都是在"符号信息不全 / 地址不可比"的环境下,通过提取"相对稳定特征"做哈希式归并。

只是当时身处嵌入式现场,没参照过这些工具,是自己独立想出来并实现的。

可以把这套套路归纳为:

当绝对值不可比时,找相对值;
当精确值不可得时,找特征值 + 容差;
当单一维度不够时,多维度交叉验证。

任何带噪声的指纹/去重场景都适用 —— 不只是崩溃栈。

7.2 算法的工程含金量,藏在"把它做成可持续工具"里

如果只把算法实现成一个 Python 函数,它的价值是有限的。

把它做成:

• 有数据流的工具
• 有持久层的资产
• 有打包发布的交付方式
• 有运营节拍的使用约定
• 有按维度汇总的视图

—— 算法才会每天都在产生回报,而不是"做完就过去了"。

很多技术博客只讲算法本身,跳过工具化和运营化。但真实工作里,算法只占代码量的小头,把它做成可持续工具的部分,才是大头。

7.3 "琐碎工作"里藏着创新点

这件事最初的定性是"比较琐碎,容易出错"。如果接受这个定性,就只会在原地用更多人工去对抗琐碎。

但琐碎、容易出错、重复做 —— 正是自动化最该出手的地方。识别这个信号,把琐碎变成算法 + 工具,就是创新点。

算法是"看到"问题,工具是"持续解决"问题。
后者比前者难,但也更值钱。