調試 - Arch Linux 中文维基

跳至內容

# 調試

出自 Arch Linux 中文维基

相關文章

- General troubleshooting
- Reporting bug guidelines
- 調試/獲取跟蹤數據
- Debugging/Profiling
- Boot debugging

翻譯狀態：

- 本文（或部分內容）譯自 Debugging，最近一次同步於 2024-08-28，若英文版本有所更改，則您可以幫助同步與翻譯更改的內容。
- 您可以在 ArchWiki 的對應頁面找到本文翻譯的原始修訂歷史。
- 本文可能與英文原文存在出入。

這篇文章的某些內容需要擴充。

原因：This article might as well be about debugging in general, so that other useful tools like ltrace包 can be added here. (在 Talk:調試 中討論)

本頁主要是關於如何收集與漏洞報告相關的更多信息。儘管使用了 「調試」 一詞，但它並不是在開發時如何調試程序的指南。

## 檢查核心轉儲的可用性

核心轉儲是進程意外終止時包含進程地址空間（內存）的文件。如果應用程式以易於調試的方式編譯，則可以使用核心轉儲文件找出問題所在。

核心轉儲的位置可能因作業系統配置而異。請參閱核心轉儲以查找系統上是否啟用了核心轉儲文件的生成以及它們的位置。

## 段錯誤

有幾種方法可用於找出問題所在。準備好成為一個真正的測試員吧！

### Gdb

gdb包 是一個古老且經過充分測試的調試器。有關如何使用它來獲取跟蹤的更多說明，請參見調試/獲取跟蹤數據#獲取跟蹤數據。從 `gdb` 運行時，您可能必須等待段錯誤。然後，將跟蹤發布到網絡剪切板上並將 URL 包含在你的錯誤報告中。

如果你有一個核心轉儲文件，它可以與 gdb 一起使用來獲得回溯：

    $ gdb appname core
    bt full

### Valgrind

假設你有一個沒有內聯函數的未剔除符號表的二進制文件，通過 valgrind包 運行該程序也是一個好方法。valgrind 是一個模擬 CPU 的工具，通常顯示哪裡出了問題，或者為提供一些 gdb 不能提供的附加信息。

    $ valgrind appname

如果發生崩潰，它將提供許多有用的調試輸出。考慮使用 `-v` 和 `--leak-check=full` 參數來獲取更多信息。

或者使用：

    $ valgrind --tool=callgrind appname

並通過 kcachegrind包 運行輸出，這樣就可以以圖形方式瀏覽程序使用的函數。如果程序掛起，這樣可以更輕鬆地查明錯誤的精確位置。

## 缺少庫或文件

### Strace

strace包 會查找應用程式執行的詳細操作。如果應用程式嘗試訪問不存在的文件，則 strace 將會發現該文件。

要查找名為 appname 的程序嘗試訪問哪些文件：

    $ strace -eopen appname

提示：如果你想從 strace 的輸出中查找特定信息，你可以運行： `strace -o /dev/stdout appname | grep string`。這將返回所有 string 出現位置周圍的輸出。

### LD_DEBUG

設置 `LD_DEBUG=files` 同樣可以大概了解應用程式正在查找的文件。對於名為 appname 的應用程式，運行：

    $ LD_DEBUG=files appname > appname.log 2>&1

程序結束後，輸出存儲在 `appname.log` 中。

對於更相信的信息，參見 ld-linux(8)。

### Readelf

如果您在運行應用程式時收到 `no such file or directory` 的錯誤提示，請嘗試以下命令：

    $ readelf -a /usr/bin/appname | grep interp

（將 `/usr/bin/appname` 替換為可執行文件的位置）

確保有問題的解釋器（如 `/lib/ld-linux-x86-64.so.2`）確實存在。如果需要，請安裝 ld-lsb包。

## 非二進制文件

在可執行文件上使用 file包 以獲取更多信息：

    $ file /usr/bin/appname

如果它顯示 `ELF`，則它是一個二進制可執行文件。如果它顯示 `Python script`，說明它是一個用 Python 編寫的應用程式。

如果它是一個 shell 腳本，請在文本編輯器中打開 shell 腳本，然後查看（通常在文件底部）是否能找到真實應用程式（ELF 文件）的名稱。然後，您可以暫時將 「gdb」 放在 shellscript 中可執行文件名稱之前，以便進行調試。請參閱前面關於 gdb 的部分。如果需要調試的可執行文件也需要參數，請在命令前加上 `gdb --args`。

對於純 shell 腳本，您還可以使用 `bash -x script_name` 或 `bash -xv script_name` 來調試。

對於 Python 應用程式，輸出通常會說明崩潰發生在哪個文件和行號。如果您精通 Python，則可以嘗試修復此問題並將修復包含在 bug 報告中。

## 報告漏洞

首先檢查有問題的 bug 是否是打包 bug。如果由於 Arch Linux 打包此應用程式的方式不當而引入該漏洞，請向 https://gitlab.archlinux.org/groups/archlinux/packaging/-/issues 報告。這還包括庫或依賴項的問題（例如，如果其中一個並不是被構建特定功能的所需）。

檢查包的 PKGBUILD，這可以通過 Arch 構建系統進行，看看它是如何打包的。

有關更多信息，請參見漏洞報告準則#上游還是_Arch？。

如果該漏洞與 Arch Linux 無關，並且可以在其他任何地方重現，則僅將其報告給上游。Arch Linux 無法神奇地修復上游錯誤。將其報告給 Arch 錯誤跟蹤器無濟於事，甚至可能適得其反，因為它往往會錯誤地浪費管理者的時間。

## 參見

- Gentoo:Project:Quality Assurance/Backtraces

分類：​

- 開發
- 系統管理

調試
新增話題