Unix & Linux: How to view core files for debugging purposes in Linux? (4 Solutions!!)
Channel: Roel Van de Paar
Date: 2020-08-10

Unix & Linux: How to view core files for debugging purposes in Linux?


The Question: I want to view the contents of a core file while debugging a program. How can I
view the contents of a core file?

Solutions: Please watch the whole video to see all solutions, in order of how many people found them helpful

== This solution helped 15 people ==
gdb is the GNU debugger which can be used to examine the core file. BTW bt
(backtrace) is a useful gdb command to examine the program call stack.
gdb binary-file core-file

== This solution helped 3 people ==
If prefer to use command line tool, then you can use http://linux.die.net/man/
1/gdb :
gdb ＜program＞ ＜core file＞
or
gdb ＜program＞ -c ＜core file＞
If you like gui, then install http://linux.die.net/man/1/ddd, and from there
open the program to debug and the core file.

== This solution helped 4 people ==
When you compile the program use -g option
gcc -g program.c
If core file is created then you can debug using gdb whithout using -g option
debug flags wont be enabled.

== This solution helped 21 people ==
objdump + gdb minimal runnable example
TLDR:
 * objdump -s core to dump memory
 * GDB to find failing line, previously mentioned at: https://
 unix.stackexchange.com/questions/89933/how-to-view-core-files-for-
 debugging-purposes-in-linux/89934#89934
Now for a the full educational test setup:
main.c
#include ＜stddef.h＞
#include ＜stdio.h＞
#include ＜stdlib.h＞
#include ＜string.h＞

int myfunc(int i) {
*(int*)(NULL) = i; /* line 7 */
return i - 1;
}

int main(int argc, char **argv) {
/* Setup some memory. */
char data_ptr[] = "string in data segment";
char *mmap_ptr;
char *text_ptr = "string in text segment";
(void)argv;
mmap_ptr = (char *)malloc(sizeof(data_ptr) + 1);
strcpy(mmap_ptr, data_ptr);
mmap_ptr[10] = 'm';
mmap_ptr[11] = 'm';
mmap_ptr[12] = 'a';
mmap_ptr[13] = 'p';
printf("text addr: %pn", text_ptr);
printf("data addr: %pn", data_ptr);
printf("mmap addr: %pn", mmap_ptr);

/* Call a function to prepare a stack trace. */
return myfunc(argc);
}
Compile, and run to generate core:
gcc -ggdb3 -std=c99 -Wall -Wextra -pedantic -o main.out main.c
ulimit -c unlimited
rm -f core
./main.out
Output:
text addr: 0x4007d4
data addr: 0x7ffec6739220
mmap addr: 0x1612010
Segmentation fault (core dumped)
GDB points us to the exact line where the segfault happened, which is what most
users want while debugging:
gdb -q -nh main.out core
then:
Reading symbols from main.out...done.
[New LWP 27479]
Core was generated by `./main.out'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000400635 in myfunc (i=1) at main.c:7
7 *(int*)(NULL) = i;
(gdb) bt
#0 0x0000000000400635 in myfunc (i=1) at main.c:7
#1 0x000000000040072b in main (argc=1, argv=0x7ffec6739328) at main.c:28
which points us directly to the buggy line 7.
Binutils analysis
First:
file core
tells us that the core file is actually an ELF file:
core: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from './
main.out'
which is why we are able to inspect it more directly with usual binutils tools.
A quick look at the http://www.sco.com/developers/devspecs/gabi41.pdf shows
that there is actually an ELF type dedicated to it:
With thanks & praise to God, and with thanks to the many people who have made this project possible! | Content (except music & images) licensed under cc by-sa 3.0 | Music: https://www.bensound.com/royalty-free-music | Images: https://stocksnap.io/license & others | With thanks to user suspectus (https://unix.stackexchange.com/users/34921), user Ozzesh (https://unix.stackexchange.com/users/38659), user ganeshredcobra (https://unix.stackexchange.com/users/24108), user Ciro Santilli ????????????? (https://unix.stackexchange.com/users/32558), user B????? (https://unix.stackexchange.com/users/5731), user Anthon (https://unix.stackexchange.com/users/33055), and the Stack Exchange Network (http://unix.stackexchange.com/questions/89933). Trademarks are property of their respective owners. Disclaimer: All information is provided "AS IS" without warranty of any kind. You are responsible for your own actions. Please contact me if anything is amiss at Roel D.OT VandePaar A.T gmail.com.