共计 713 个字符，预计需要花费 2 分钟才能阅读完成。
问题
在 09 问中，咱们开启了 coredump 性能，在 MySQL 解体时取得了有用的 coredump 信息。
那如果没开启 coredump，仅有 error log 中的堆栈信息，咱们如何剖析无效的信息？
试验
咱们沿用 09 问中的 MySQL 解体的场景，此处疏忽复现解体的步骤，大家参看 09 问查看 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 这个函数外部的一段代码。
对于 MySQL 的技术内容，你们还有什么想晓得的吗？连忙留言通知小编吧！
