见我
$ 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`
——我提供了一个来自stdin的字符串，并且…——
Segmentation fault (core dumped)
根据Arch wiki，"Systemd的默认行为是为/var/lib/systemd/coredump/中的所有进程生成核心转储。"
农夫移民doke:
$ls /var/lib/systemd/coredump/core.1x2e13x2ex.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.1x2e13x2ex.1000.0da6be3a2b4647c8befe14e0e73af848.1719.1438627150000000.lz4" is not a core dump: File format not recognized
尝试通过将GDB附加到这里详细说明的进程来生成核心转储，只会使我的终端模拟器开始捕获控制字符(^D, ^C和^Z在附加GDB后不会在模拟器中工作)，并且如果在附加GDB后发生段错误，则不会在shell中报告。
帮助我理解，哦，仁慈的Stack Overflow领主!
附录:
我已经解决了这个特殊的问题，很大程度上要感谢WhozCraig，他建议GDB在被强制输入lz4压缩的核心文件时表现得像它应该有的那样。如果克雷格能好心地发表一个类似的解决方案，我很乐意给他打个大大的"老"勾。
最简单的解决方案是通过名为coredumpctl的子例程以及崩溃程序的PID启动gdb，如
所示。 $coredumpctl gdb *PID HERE*
Arch，这让我很烦恼，我可能会因此迁移到Gentoo。
我已经解决了这个特殊的问题，很大程度上要感谢WhozCraig，他建议GDB在被强制输入LZ4压缩的核心文件时表现得像它应该的那样。如果Craig能发一个类似的解决方案，我很乐意给他一个大大的勾号我要把所有的功劳都记在自己身上。Bwahahaha !
$coredumpctl gdb PID HERE
这让我很烦恼，Arch，我可能会因为它而迁移到Gentoo。
我和你有同样的目的。通过lz4命令解压lz4文件，然后可以通过gdb crashed_C_executable_file uncompressed_coredump_file