從FreeBSD的內核核心轉儲中提取用戶空間線程堆棧

我想在FreeBSD上調試多進程解決方案。當系統/設備遇到類似情況的掛起時，我們通過'sysctl debug.panic = 1'強制內核轉儲。意圖是在相同的時間點捕獲所有進程的狀態。但是，我是無法查看用戶空間應用程序的線程堆棧。使用'ps'，我能夠列出所有用戶空間進程/線程，但無法設置其堆棧幀並使用'bt'展開。從FreeBSD的內核核心轉儲中提取用戶空間線程堆棧

是否有可能實現類似於我正在嘗試執行的操作？我已經看到OpenVMS 調試器（IIRC甚至windbg）允許一個人窺探到用戶空間線程。

來源

2011-11-27 hackworks

使用DDB。它支持跟蹤線程。見this article。同一篇文章還命名kgdb命令來跟蹤用戶空間線程。但是這些不在手冊頁中。 :-(

來源

2012-03-05 00:18:21

謝謝，讓我通讀它 – hackworks

在DDB「BT/U」將跟蹤線程的堆棧的用戶空間部分。見「人4 DDB」，即，與textdump結合可能是不夠的。

如果你有工作是核心，事情變得更加複雜

在kgdb中，「info threads」會列出內核崩潰時正在運行的所有線程，然後「thread X」後跟「bt」會給你in-kernel部分線程堆棧

獲取應用程序的userland部分將會更困難。最簡單的方法可能是修改gcore應用程序，以便我t使用libkvm挖掘與給定進程關聯的虛擬機結構，並基本上重建進程的核心轉儲。這是可能的，但我認爲目前還沒有現成的解決方案。

來源

2012-03-28 06:56:56 ArtemB

他們已經刪除了設備上的ddb，它可以變得更難...讓我先找到一個工作ddb，看看我能走多遠。我在linux上使用交叉編譯的gdb – hackworks

對於調試FreeBSD內核核心，常規GDB可能並不是那麼有用。首先，並非所有內核核心格式都是「標準」的。例如，FreeBSD的KGDB與libkvm鏈接，它知道如何處理小型轉儲（這是目前的默認值）。至少你需要使用'sysctl debug.minidump = 0'禁用小轉儲，以便生成的核心處於正常的ELF格式。即便如此，核心將有*物理*內存轉儲，GDB將需要libkvm以將內核虛擬地址轉換爲物理地址。 – ArtemB

從FreeBSD的內核核心轉儲中提取用戶空間線程堆棧

回答

相關問題