問題

在?09 問中，我們開啟了 coredump 功能，在 MySQL 崩潰時(shí)獲得了有用的 coredump 信息。

那如果沒開啟 coredump，僅有 error log 中的堆棧信息，我們?nèi)绾畏治鲇行У男畔?#xff1f;

實(shí)驗(yàn)

我們沿用?09 問中的 MySQL 崩潰的場(chǎng)景，此處忽略復(fù)現(xiàn)崩潰的步驟，大家參看 09 問查看 error log：

我們拿到了崩潰位置 0xee36f1，如何找到與之相對(duì)的代碼位置呢？找臺(tái)測(cè)試機(jī)，獲取對(duì)應(yīng)版本的安裝包：

解壓：

然后用 GDB 打開 mysqld：

在 0xee36f1 位置打一個(gè)斷點(diǎn)：

我們可以看到，gdb 將崩潰位置的文件名和行號(hào)都打印出來，剩下的事情，就可以交給開發(fā)工程師，按照這個(gè)崩潰堆棧來進(jìn)行問題排查。

贈(zèng)送章節(jié)

紅框內(nèi)的這串信息是什么？我們來解開看一下，這段信息分為兩段，"+0x71" 是一個(gè)偏移量，前面是一串文字，我們將文字解析出來：

可以看到前面這串文字是一個(gè)函數(shù)簽名的編碼，用 c++filt 還原編碼以后，可以看到完整的函數(shù)簽名。紅框內(nèi)的這串信息的意思就是崩潰位置是 一個(gè)函數(shù)起始位置 + 偏移量。我們大概可以猜到，這個(gè) MySQL 的缺陷是在為 binlog 產(chǎn)生新的文件名時(shí)發(fā)生的。

小貼士：

函數(shù)起始位置 + 偏移量 是一種內(nèi)存位置的表示方法，但該位置不一定是這個(gè)函數(shù)內(nèi)的代碼。

以本例來說，0xee36f1 這個(gè)位置，程序找到了就近的函數(shù) generate_new_name 的起始位置，計(jì)算出有 0x71 這么多偏移，就表示成了 generate_new_name+0x71 這種形式。

但 0xee36f1 這個(gè)位置的代碼，大概率是，但，不一定是 generate_new_name 這個(gè)函數(shù)內(nèi)部的一段代碼。

關(guān)于 MySQL 的技術(shù)內(nèi)容，你們還有什么想知道的嗎？趕緊留言告訴小編吧！

總結(jié)

以上是生活随笔為你收集整理的linux打印mysql堆栈_第25问：MySQL 崩溃了，打印了一些堆栈信息，怎么读？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。