第25问:MySQL 崩溃了,打印了一些堆栈信息,怎么读?

image

问题

在 09 问中,我们开启了 coredump 功能,在 MySQL 崩溃时获得了有用的 coredump 信息。

那如果没开启 coredump,仅有 error log 中的堆栈信息,我们如何分析有效的信息?

实验

我们沿用 09 问中的 MySQL 崩溃的场景,此处忽略复现崩溃的步骤,大家参看 09 问查看 error log:

第25问:MySQL 崩溃了,打印了一些堆栈信息,怎么读?_第1张图片

我们拿到了崩溃位置 0xee36f1,如何找到与之相对的代码位置呢?找台测试机,获取对应版本的安装包:

第25问:MySQL 崩溃了,打印了一些堆栈信息,怎么读?_第2张图片

解压:

image

然后用 GDB 打开 mysqld:

第25问:MySQL 崩溃了,打印了一些堆栈信息,怎么读?_第3张图片

在 0xee36f1 位置打一个断点:

image

我们可以看到,gdb 将崩溃位置的文件名和行号都打印出来,剩下的事情,就可以交给开发工程师,按照这个崩溃堆栈来进行问题排查。

赠送章节

第25问:MySQL 崩溃了,打印了一些堆栈信息,怎么读?_第4张图片

红框内的这串信息是什么?我们来解开看一下,这段信息分为两段,"+0x71" 是一个偏移量,前面是一串文字,我们将文字解析出来:

image

可以看到前面这串文字是一个函数签名的编码,用 c++filt 还原编码以后,可以看到完整的函数签名。红框内的这串信息的意思就是崩溃位置是 一个函数起始位置 + 偏移量。我们大概可以猜到,这个 MySQL 的缺陷是在为 binlog 产生新的文件名时发生的。

小贴士:
函数起始位置 + 偏移量 是一种内存位置的表示方法,但该位置不一定是这个函数内的代码。
以本例来说,0xee36f1 这个位置,程序找到了就近的函数 generate_new_name 的起始位置,计算出有 0x71 这么多偏移,就表示成了 generate_new_name+0x71 这种形式。
但 0xee36f1 这个位置的代码,大概率是,但,不一定是 generate_new_name 这个函数内部的一段代码。


关于 MySQL 的技术内容,你们还有什么想知道的吗?赶紧留言告诉小编吧!

image

你可能感兴趣的:(mysql)