問題

在?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 的技術內容，你們還有什么想知道的嗎？趕緊留言告訴小編吧！

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。