How to view Core file (general)

Question

Scenario (Ubuntu 16.04):

I compile and run a C program (with -g, I get the traditional Segmentation Fault (core dumped), and then (of course) there is no mythical "core" file to be found. Some digging says to modify /proc/sys/kernel/core_pattern with a command to the effect of: echo '|tee /home/me/my_core_folder/my_core_file' | sudo tee /proc/sys/kernel/core_pattern, and after doing this, I stop getting (core dumped) and start only getting the plain Segmentation Fault. I try things like gdb ./program_object_file.out core.pid which obviously doesn't exist (I was getting desperate), and of course try the plain gdb ./a.out followed by (gdb) core core.pid and variants of the commands where I spam the tab key desperately trying to get auto-completion to get me to where I need to be.

Question:

Is there a generalized way I can get to core dumps? I recognize that every machine that I touch seems to have a Michael Bay's Transformers-esque ability to reconfigure hardware and software such that no device I own can be expected to work normally out-of-the-box. Is there a simple algorithm/recipe I can follow to locate core dumps on my own machine as well as on other peoples' machines? I always find myself tutoring friends on stuff like this after no small amount of work to get things working for myself and it would be nice to be able to run a command or something to get core files dumped to the directory which the executable was run from... is there any way to do this that should work on most (I would settle for "some") Linux/Unix machines?

Answer 1

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.

Answer 2

(Moving an answer from OP in the Question to an Answer)

I marked the answer below as the correct answer since it helped me to identify what was actually going wrong, and I would like to return in the future to flesh out this a little more, but my current solution (that I suspect would work on most Linux machines) is to use the following commands-

cat /proc/sys/kernel/core_pattern > ~/.core_pattern.bak 
echo '|/usr/bin/tee ~/path_you_wish_to_dump_to/core/dump' | sudo tee /proc/sys/kernel/core_pattern

This will back up your previous core dumping method into a hidden file (.core_pattern.bak) in your home folder which can be restored with

sudo cp ~/.core_pattern.bak /proc/sys/kernel/core_pattern

and the second command will cause core dumps to be dumped to a folder named core as a file named dump. Obviously you can tinker with this format to get a pattern more to your liking. It should be noted, however, that as far as I can tell, this will only store one core dump at a time (each new one will clobber old ones) but since, if I personally ever check a core dump, it is for the program which just ran, and since I have no need to keep old dumps, this is a good solution for me and for most of the applications my friends will be creating and debugging. I would love to modify this answer some more down the road to include things like the PID which caused the segfault (mostly just sugar on top, since -again -I typically know which program caused the segfault, since I just ran it) but this will certainly suffice for me and for a lot of people I would imagine.

Last but not least, to actually view the dump, simply run the command:

gdb ./executable_that_crashed ~/path_you_wish_to_dump_to/core/dump

Assuming you are in the folder where you compiled/ran the executable that is getting the segfault.