sprinigboot mysql打印sql mysql 打印调试信息_偏移量

问题

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

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

实验


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

查看 error log:

sprinigboot mysql打印sql mysql 打印调试信息_偏移量_02


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

sprinigboot mysql打印sql mysql 打印调试信息_偏移量_03


解压:

sprinigboot mysql打印sql mysql 打印调试信息_偏移量_04


然后用 GDB 打开 mysqld:

sprinigboot mysql打印sql mysql 打印调试信息_MySQL_05


在 0xee36f1 位置打一个断点:

sprinigboot mysql打印sql mysql 打印调试信息_数据_06


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

赠送章节

sprinigboot mysql打印sql mysql 打印调试信息_偏移量_07


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

sprinigboot mysql打印sql mysql 打印调试信息_数据_08


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

小贴士:


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

关于爱可生

上海爱可生信息技术股份有限公司是国内开源数据库解决方案领导者、工业互联网高维数据应用创新者。爱可生为产业互联网创新应用提供高性价比、快速落地实现的多数据库管理平台、分布式数据库系统、数据库容器云平台、多地多中心跨云容灾等解决方案。

在工业互联网相关垂直行业,深入分析数据价值,构建数据中台和业务中台的基础软件PaaS平台,用数据技术驱动企业高质量增长。公司产品已被广泛应用于各行业,累计用户超过400家,其中包括工商银行、中国人寿、中国太保、国家电网、上汽集团、中国移动、华为等30多家世界500强企业。