debugging

5 posts

你的 main 分支挂了,要从 200 个 commit 里找出元凶

Git bisect 把手动翻 commit 变成了自动二分查找。以下是如何在不逐个 checkout 的情况下,精确定位引入 bug 的 commit。

你的 CI 在 main 上红了,但昨天还是绿的。在那之后到现在之间的某个时刻,一个 bug 溜了进来。你可以滚动浏览 200 个 commit,阅读 diff 并猜测。你可以在 Slack 里问,指望有人记得碰过相关代码。或者你可以让 Git 来干活。 是一个针对你 commit 历史的二分查找工具。你标记一个…

你的错误追踪器知道崩溃发生在哪里,但这无法帮你复现它

堆栈追踪告诉你崩溃发生的位置,而不是原因。以下是一种捕获-复现模式,能把生产环境崩溃转化为本地可调试的测试用例。

你确切知道生产环境在哪里崩溃了。堆栈追踪指向 的第 147 行。异常是一个针对 的 。你拉下代码,运行测试,全部通过。你用一个示例 payload 手动命中端点,它工作正常。 Bug 是真实的。客户在触发它。但你就是没法在自己的机器上复现。…

Crash Correlation 会说谎。以下是如何让它们指向真正的 Bug。

Statistical debugging 找到与崩溃相关的 predicates,但相关性不是文件和行号。以下是如何通过排序、过滤和三角测量,从相关性分数找到实际的 bug 位置。

Statistical debugging 给你的是 predicates 的排序列表,而不是根因。你对每个分支和 null check 进行插桩,运行十万次执行,算法给你一个记分板。 处的 的 importance 为 0.94。 处的 也是。其中一个是 bug。另一个只是每当程序崩溃时就恰好为真。…

Statistical debugging 本应终结 printf 调试时代。但大多数团队从未让它真正运转起来。

Statistical debugging 承诺通过将程序行为与故障相关联来精确定位 bug。以下是为什么这个想法从未从研究论文跨越到生产系统。

Statistical debugging 本应终结 时代。对你的代码进行插桩,从数千次运行中收集 trace,运行相关性分析,然后看着工具按照导致崩溃的可能性对每一个分支和 null check 进行排序。它在 2000…

看不懂突变改了什么,怎么写测试杀死它?

mutation testing 发现了一个 survivor,但你根本不知道这个 mutation 做了什么。这里有一个分步方法,让你不用先理解 mutant 也能写出正确的测试。

你的 mutation testing 报告里全是 survivor,其中至少有一个你完全看不懂。 工具说它把第 47 行的 换成了 ,或者把整个条件块替换成了 ,又或者变异了一个你根本不知道正在被测试的字符串字面量。你 diff 看了三遍。你还是不明白这个 mutant…