调试
本页主要是关于如何收集与漏洞报告相关的更多信息。尽管使用了 “调试” 一词，但它并不是在开发时如何调试程序的指南。
检查核心转储的可用性[编辑 | 编辑源代码]
核心转储是进程意外终止时包含进程地址空间（内存）的文件。如果应用程序以易于调试的方式编译，则可以使用核心转储文件找出问题所在。
核心转储的位置可能因操作系统配置而异。请参阅核心转储以查找系统上是否启用了核心转储文件的生成以及它们的位置。
段错误[编辑 | 编辑源代码]
有几种方法可用于找出问题所在。准备好成为一个真正的测试员吧！
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 -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 错误跟踪器无济于事，甚至可能适得其反，因为它往往会错误地浪费管理者的时间。