GDB 和核心转储问题

Posted 2023-02-22

【中文标题】GDB 和核心转储问题

【英文标题】：GDB and trouble with core dumps

【发布时间】：2015-08-03 20:09:50

【问题描述】：

认识我的

$ uname -a
Linux hostmachine 4.1.2-2-ARCH #1 SMP PREEMPT Wed Jul 15 08:30:32 UTC 2015 x86_64 GNU/Linux

我正在尝试学习如何使用 GDB 来调试 C 程序。我认为如果我可以使用 GDB 找出导致段错误的错误，那将是特别好的。我写了一个小程序，作为 K&R 练习 1-13 的解决方案，给定一个特定大小的输入字符串，它会生成一个段错误：

$ ~/learning_c/KR_exercises/chapter_1/1.13.x`

--我从标准输入提供一个字符串，然后...--

Segmentation fault (core dumped)

根据Arch wiki，“Systemd 的默认行为是为/var/lib/systemd/coredump/ 中的所有进程生成核心转储。”

好的多克：

$ls /var/lib/systemd/coredump/core.1\x2e13\x2ex.1000.0da6be3a2b4647c8befe14e0e73af848.1719.1438627150000000.lz4

但是当我跑步时：

$ gdb -q ~/learning_c/KR_exercises/chapter_1/1.13.x /var/lib/systemd/coredump/core.1\\x2e13\\x2ex.1000.0da6be3a2b4647c8befe14e0e73af848.1719.1438627150000000.lz4

我明白了：

Reading symbols from /home/dean/learning_c/KR_exercises/chapter_1/1.13.x...done.
"/var/lib/systemd/coredump/core.1\x2e13\x2ex.1000.0da6be3a2b4647c8befe14e0e73af848.1719.1438627150000000.lz4" is not a core dump: File format not recognized

尝试通过将 GDB 附加到进程 as detailed here 来生成核心转储只会使我的终端模拟器开始捕获控制字符（^D、^C 和 ^Z 在附加 GDB 后将无法在模拟器中工作） ，并且如果在附加 GDB 后发生段错误，则不会在 shell 中报告。

帮助我理解，哦，Stack Overflow 的仁慈仁慈的领主！

附录：

我已经解决了这个特殊问题，这在很大程度上要感谢 WhozCraig，他建议 GDB 在被强制输入 lz4 压缩核心文件时表现得应该有。如果 Craig 愿意发布一个类似的解决方案，我会很乐意给他那个大大的 'ol 复选标记。

最简单的解决方案是通过名为coredumpctl 的子例程以及崩溃程序的PID 启动gdb，例如

$coredumpctl gdb *PID HERE*

这让我很烦恼，Arch，我可能会因此迁移到 Gentoo。

【问题讨论】：

没有我的 linux 机器，我只能推测 gdb 正在呕吐，因为它 认为 是原始核心转储？请注意，这只是一个猜测，但也许值得一看。

这是一个完全合理的解决方案！现在我很尴尬，因为我不认识 .lz4 文件扩展名。等我读完 lz4 上的相关文档并设法解压核心文件后，我会回来报告！

您是否尝试过设置断点并使用 GDB 单步执行程序？

@Rdesmond，我可以。而且，对于像我正在使用的小程序，这种方法可能与检查核心转储一样有效（可能更快）。不过，我的目标是学习如何 使用核心转储。假设未来的假设程序很大，或者在段错误之前运行了真的很长时间，或者行为依赖于一堆随机环境输入？能够使用核心文件使得在这些场景中的调试变得不那么繁琐。

查看此页面freedesktop.org/software/systemd/man/journald.conf.html 似乎默认情况下，如果核心大小更大，它们会被压缩。您需要做的就是将 Compress 值设置为 false

【参考方案1】：

我已经解决了这个特殊问题，这在很大程度上要感谢 WhozCraig，他建议 GDB 在被强制输入 LZ4 压缩核心文件时表现得应该有。 如果 Craig 愿意发布一个类似的解决方案，我会很乐意给他那个大大的 'ol 复选标记 不过，我将承担所有功劳。哇哈哈哈！

最简单的solution 是通过名为 coredumpctl 的子例程以及崩溃程序的 PID 启动 gdb，例如

$coredumpctl gdb 这里的PID

这让我很烦恼，Arch，我可能会因此迁移到 Gentoo。

【讨论】：

最简单的就是coredumpctl gdb -1 来调试最新的转储。

是的，您正试图打开一个压缩文件，就好像它是一个核心转储一样。 Arch 不是罪魁祸首，systemd 是，你不知道 coredump 发生了什么变化。如果你想要旧的行为，将 /proc/kernel/core_pattern 改回“core”，或者只使用 coredumpctl gdb

【参考方案2】：

我和你有同样的目的。只需通过lz4命令解压lz4文件，即可通过gdb crashed_C_executable_file uncompressed_coredump_file调试

【讨论】：

如果使用 coredumpctl gdb，则无需解压或重新压缩。