We have a process that keeps producing a core dump file but not even sure which process. I have followed instructions to use the crash utility to analyse the core dump file. I had to install a new repo and install crash. Now it is running I get this:
crash: /usr/lib/debug/lib/modules/3.10.0-229.14.1.el7.x86_64/vmlinux and /home/user/d336599/core.26061 do not match!
Any idea the solution?
If you use the file command on the core dump, it should be able to tell you the name of the executable that produced the core dump file.
Then gdb <executable file> <core dump file> will start up gdb, and the bt command in gdb will produce a backtrace of the program crash.
But if the debugging symbols have been stripped out of the executable, you'll find that the backtrace will not be very informative. In that case, you might have to find a separate debugging symbol table file for that executable (version must match exactly) and add the -s <symbol table file> to the gdb command invocation.
If the core dump is truncated, you're most likely running out of disk space (as you stated in the comments). The core file name /home/user/d336599/core.26061 indicates you're probably using RHEL7 sysctl default values kernel.core_pattern = "core" and kernel.core_uses_pid = 1. By specifying an absolute pathname in kernel.core_pattern sysctl, you can redirect core dumps to another disk with more space. Just remember to make sure the directory is writeable for the user that owns the program that is dumping the core.
See man 5 core for more information on how you can use kernel.core_pattern to specify where core dump files will be generated and how to name them.
crashutility is for analyzing kernel crashes, not core dumps. You would typically usegdbfor analyzing a core dump.