十四小时极限调试挑战 – 流水账
背景
本文以流水线的方式记录了一次难以忘怀的调试经历。
过程
2019-10-29 13:02 分
接到紧急报告，某商业软件在解析特定数据格式时候出现故障，需要立即解决。而无法联系到供应商。
2019-10-29 13:20 分
开始进行问题复现。
2019-10-29 14:26 分
问题复现成功，打开 debug 级别日志，希望从日志中找出线索。
2019-10-29 14:40 分
日志没有记录到更有效的信息，开始对程序安装目录进行结构分析。
2019-10-29 15:30 分
基本完成对程序的分析，主要使用 Java 和 so 进行链接，由于程序是非常模块化的，基本可以定位到某几个 Jar 包有 Bug.
2019-10-29 15:50 分
从 Jar 包的名称中发现在一个关键位置可能是引入了一个开源库，通过 Google 找到该项目源码，希望通过修改这个库以避免这个 Bug。
2019-10-29 17:10 分
第一个版本的修改版完成，尝试替换，解决了一定的问题，缩小了问题发生几率，但仍旧没有实际的进展。
2019-10-29 19:00 分
吃了个晚餐。
2019-10-29 19:20 分
经过两个小时的奋战，基本宣告这个方案失败，开始预备尝试对某个私有内部 JAR 包进行修改的方案。
2019-10-29 21:30 分
通过 JBE 将 JAR 包进行反编译，开始尝试直接修改 Class 文件。
2019-10-29 22:30 分
完成了 Class 文件修改版，进行替换后无法正常工作，造成了运行时的直接崩溃。
2019-10-29 22:50 分
喝了一杯焦糖加浓美式。
2019-10-29 23:10 分
通过上一个步骤对 Jar 的反编译已经发现源码没有进行加密与混淆，开始将整个 JAR 包进行反编译得到源代码，并且直接将该程序的所有 JAR 包都纳入 lib 中，开始直接编译。
2019-10-30 01:15 分
项目构成完成，解决了源代码中的一些问题，对代码进行非破坏性的增加日志。上线一个版本。
2019-10-30 01:30 分
拿到更完整的日志，进行日志分析。对代码进行保护性调整，进行了多次 Debug。
2019-10-30 02:20 分
基本宣告调试完成，进行完整验证。在验证过程中，发现有部分逻辑遗漏。
2019-10-30 03:20 分
完成了最终版本，调试通过。
2019-10-30 03:30 分
正式投入使用，替代旧版程序。将整个问题 Email 复现给了供应商。
2019-10-30 04:00 分
记录下来了这次难得可贵的经历。