The core(5)
manpage describes the parameters affecting core dumps in detail, including their naming etc.
To answer your stated question, there is no generalisable way to find a core dump. By default, core is dumped in the process's current working directory, if the process is allowed to write there, if there's enough room on the containing filesystem, if there's no existing core dump (under some circumstances), and if the file size and core file size limits (as set by ulimit
or similar mechanisms) allow it. But /proc/sys/kernel/core_pattern
provides many different ways of processing core dumps, so you really need to look at that too and figure out what's going on.
In your case, I don't know why the core couldn't be found initially, but I do know why you stopped getting cores after setting the redirection up: when using a pipe in core_pattern
, the processing program must be specified using an absolute pathname. tee
on its own won't be used; you need to specify /usr/bin/tee
. Note that you should take particular care with this type of setup on multi-user systems, because the program run to process the core dump is run as root
.
On Debian derivatives I install corekeeper
, which writes core dumps in an easily-usable manner to per-user directories under /var/crash
.
Best Answer
objdump
+gdb
minimal runnable exampleTLDR:
objdump -s core
to dump memoryGDB to find failing line, previously mentioned at: How to view core files for debugging purposes in Linux?
Now for a the full educational test setup:
main.c
Compile, and run to generate core:
Output:
GDB points us to the exact line where the segfault happened, which is what most users want while debugging:
then:
which points us directly to the buggy line 7.
Binutils analysis
First:
tells us that the
core
file is actually an ELF file:which is why we are able to inspect it more directly with usual binutils tools.
A quick look at the ELF standard shows that there is actually an ELF type dedicated to it:
Further format information can be found at:
Then:
gives some hints about the file structure. Memory appears to be contained in regular program headers:
and there is some more metadata present in a notes area, notably
prstatus
contains the PC:objdump
can easily dump all memory with:which contains:
which matches exactly with the stdout value in our run.
Tested in Ubuntu 16.04 amd64, GCC 6.4.0, binutils 2.26.1.