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