GDB and trouble with core dumps

Question

Meet my

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

I'm trying to learn how to use GDB for debugging C programs. I think it would be particularly excellent if I could use GDB to ferret out bugs that lead to segfaults. I have a small program that I've written as a solution to K&R's exercise 1-13, and given an input string of a certain size it will generate a segfault:

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

--I provide a string from stdin, and...--

Segmentation fault (core dumped)

According to the Arch wiki, "Systemd's default behavior is to generate core dumps for all processes in /var/lib/systemd/coredump/."

Okie doke:

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

But when I run:

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

I get:

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

Trying to generate a core dump by attaching GDB to the process as detailed here only makes my terminal emulator start capturing control characters (^D, ^C, and ^Z won't work in emulator after attaching GDB), and if a segfault is occuring after attaching GDB it isn't being reported in the shell.

Help me to understand, oh merciful and beneficent lords of Stack Overflow!

ADDENDUM:

I've solved this particular issue, thanks largely to WhozCraig, whom suggested that GDB was behaving as it should have when being force-fed an lz4 compressed corefile. If Craig would be so kind as to post a solution saying something similar, I'd be happy to give him that big 'ol check mark.

The easist solution is to start gdb via a subroutine named coredumpctl along with the crashed program's PID, a la

$coredumpctl gdb *PID HERE*

This vexes me, Arch, and I may migrate over to Gentoo because of it.

Answer 1

I've solved this particular issue, thanks largely to WhozCraig, whom suggested that GDB was behaving as it should have when being force-fed an LZ4 compressed corefile. If Craig would be so kind as to post a solution saying something similar, I'd be happy to give him that big 'ol check mark I'm taking all the credit, though. Bwahahaha!

The easiest solution is to start gdb via a subroutine named coredumpctl along with the crashed program's PID, a la

$coredumpctl gdb PID HERE

This vexes me, Arch, and I may migrate over to Gentoo because of it.