根据崩溃日志查找已修复BUG

排查工具准备

gdb、chrome及Sourcegraph插件、VScode及Sourcegraph插件

确定Crash位置

1. 查看当前错误日志

MySQL异常崩溃，查看error日志，红框处为位置信息

注：如出现这种类似BUG信息，不应只看这部分信息，应先查看MySQL异常退出前是否存在报错信息。

2. gdb查看报错文件位置

使用gdb追踪报错文件位置，前面报错文件为mysqld,就gdb mysqld文件，如果是其他的文件，例如组复制插件，那么就gdb该文件

首先先b一下函数名称，如下所示

可以看出后面找到两个位置，然后我们再加上偏移量，再b一下

很明显，第二个找到的是mysql里文件，从官方上下载相同版本源码包进行解压，找过pipeline_stats.h这一文件中的410行，确定函数名为Pipeline_member_stats()

新旧代码对比

1. 打开故障版本MySQL对应的github代码库并加载Sourcegraph插件

根据路径打开代码文件

 

2. 在另一个窗口中打开最新MySQL版本的对应代码文件

 

3. 打开VScode软件

注：需提前安装好sourcegraph扩展

将第一步骤中sourcegraph的路径复制到vscode的路径中打开

同理在VScode里面打开最新版的代码文件

快捷键Ctrl+Shift+p打开VSCode命令行，输入compare进行代码对比

在最近打开的文件里面选择另外一个代码文件

此时就会显示出两个代码文件的对比结果，看到新增或删除的代码，比如我们在故障位置所在的附近及所在函数里找到了很多代码的变更

查看代码变更，寻找相关Bug

打开浏览器里面的Sourcegraph的最新MySQL版本的代码文件，并开启git blame

在故障位置点附近及所在函数或类里面查看Bug

可以点击打开对应Bug查看和遇到的现象是否相匹配

也可以在show history里面查看历史Bug

在MySQL官网的Release Notes里也能找到是在8.0.20版本修复该bug

结语

文章内主要提到通过error日志找到当前已经修复的bug。碰到error日志中有上述报错，应该先对崩溃前的报错进行分析，部分的崩溃报错不用通过堆栈的方式定位就能找到问题。如碰到目前还未修复或者修复bug时并没有对该段代码进行直接修改时，可能会失效，这时候需要对堆栈指向的代码进行梳理，搞清楚这部分逻辑，再分析。

 

如果是将之前的代码删除了，在页面上无法直接看到bug,可以查看具体这个代码文件所有的提交更新记录。