问题
在 09 问 中，我们开启了 coredump 功能，在 MySQL 崩溃时获得了有用的 coredump 信息。
那如果没开启 coredump，仅有 error log 中的堆栈信息，我们如何分析有效的信息？
实验
我们拿到了崩溃位置 0xee36f1，如何找到与之相对的代码位置呢？
找台测试机，获取对应版本的安装包：
解压：
然后用 GDB 打开 mysqld：
在 0xee36f1 位置打一个断点：
我们可以看到，gdb 将崩溃位置的文件名和行号都打印出来，
剩下的事情，就可以交给开发工程师，按照这个崩溃堆栈来进行问题排查。
赠送章节
红框内的这串信息是什么？我们来解开看一下，
这段信息分为两段，”+0x71″ 是一个偏移量，前面是一串文字，我们将文字解析出来：
可以看到前面这串文字是一个函数签名的编码，用 c++filt 还原编码以后，可以看到完整的函数签名。
红框内的这串信息的意思就是崩溃位置是 一个函数起始位置 + 偏移量。
我们大概可以猜到，这个 MySQL 的缺陷是在为 binlog 产生新的文件名时发生的。
小贴士：
函数起始位置 + 偏移量 是一种内存位置的表示方法，但该位置不一定是这个函数内的代码。
以本例来说，0xee36f1 这个位置，程序找到了就近的函数 generate_new_name 的起始位置，计算出有 0x71 这么多偏移，就表示成了 generate_new_name+0x71 这种形式。
但 0xee36f1 这个位置的代码，大概率是，但，不一定是 generate_new_name 这个函数内部的一段代码。