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.
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.
I have same purpose with you. Just uncompress lz4 file by lz4 command, then you can debug by gdb crashed_C_executable_file uncompressed_coredump_file