How to view and back trace core dumps through gdb
Tags: c, linux, cpp, beginners
Published: 2022-12-24 05:56:07

## Write a sample program that generates a segmentation fault
In Ubuntu, core dumps are not generated by default. If you want the system to generate core dump, you need to enter the following command:

```bash
ulimit -c unlimited
```

In the above command, ulimit is to limit the usage of some user resources, including max user processes, the upper limit of open files, the upper limit of virtual memory, etc., and `ulimit -c` is to set the size of the core, `unlimited` means no upper limit, if you want To limit the size of the core, you can change `unlimited` to other numbers.

Next I wrote a test file that will cause a segmentation fault when executed:

```c
/* myprogram.c */
int main() {
    int *i;
    *i = 1;     // Assign before malloc
    return 0;
}
```

Add `-g` debug option when compiling, and then execute:

```bash
gcc -g myprogram.c -o myprogram
./myprogram
Segmentation fault (core dumped)
```

At this time, there should be a file named `core` left in the current directory, see **Method 1**. If the file is not found, it means that the Linux version is relatively new, so you may not use this method, but use `coredumpctl` to manage core dumps, see **Method 2**.

## Method 1
At this time, we want to find out where the program is wrong, so open gdb and enter the program name and core file name:

```
gdb myprogram core
GNU gdb (Ubuntu 9.1-0ubuntu1) 9.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from myprogram...
[New LWP 3355]
Core was generated by `./myprogram'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000056139bf2f135 in main () at myprogram.c:4
4		*i = 1;
(gdb) q
```

## Method 2
Install `systemd-coredumpctl`:

```bash
sudo apt install systemd-coredump
```

Then use coredumpctl to list the core dump records of `myprogram`:

```
TIME                          PID  UID  GID SIG     COREFILE EXE                                SIZE
Sun 2022-10-02 19:52:44 CST 61547 1000 1000 SIGSEGV present  /home/lin/Desktop/test/c/myprogram 18.1K
```

Then tell gdb to open the core dump with `coredumpctl debug myprogram`:

```
coredumpctl debug myprogram
           PID: 61547 (myprogram)
           UID: 1000 (lin)
           GID: 1000 (lin)
        Signal: 11 (SEGV)
     Timestamp: Sun 2022-10-02 19:52:44 CST (1min 0s ago)
  Command Line: ./myprogram
    Executable: /home/lin/Desktop/test/c/myprogram
 Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-org.gnome.Terminal.slice/vte-spawn-f9eab066-b8f1-4ae9-8e21-14c78f25dbe0.scope
          Unit: user@1000.service
     User Unit: vte-spawn-f9eab066-b8f1-4ae9-8e21-14c78f25dbe0.scope
         Slice: user-1000.slice
     Owner UID: 1000 (lin)
       Boot ID: cbadc919c16149c8ae41b0a2ff2a94d4
    Machine ID: bd90775ca2c24d75929026d99304a7c2
      Hostname: Aspire7
       Storage: /var/lib/systemd/coredump/core.myprogram.1000.cbadc919c16149c8ae41b0a2ff2a94d4.61547.1664711564000000.zst (present)
     Disk Size: 18.1K
       Message: Process 61547 (myprogram) of user 1000 dumped core.
                
                Found module /home/lin/Desktop/test/c/myprogram with build-id: 95d32ba05adbce1c07d8f4a8c4eff5acf5a96cf8
                Found module linux-vdso.so.1 with build-id: 88536f03982667a41f2be85c4e61e7e8307e2700
                Found module ld-linux-x86-64.so.2 with build-id: 61ef896a699bb1c2e4e231642b2e1688b2f1a61e
                Found module libc.so.6 with build-id: 69389d485a9793dbe873f0ea2c93e02efaa9aa3d
                Stack trace of thread 61547:
                #0  0x000055983cee5135 n/a (/home/lin/Desktop/test/c/myprogram + 0x1135)
                #1  0x00007fc884842d90 __libc_start_call_main (libc.so.6 + 0x29d90)
                #2  0x00007fc884842e40 __libc_start_main_impl (libc.so.6 + 0x29e40)
                #3  0x000055983cee5065 n/a (/home/lin/Desktop/test/c/myprogram + 0x1065)

GNU gdb (Ubuntu 12.0.90-0ubuntu1) 12.0.90
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/lin/Desktop/test/c/myprogram...
[New LWP 61547]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./myprogram'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000055983cee5135 in main () at myprogram.c:4
4	    *i = 1;
(gdb) q
```

## Use the `bt` Instruction for Back Trace
In the previous example, gdb successfully helped me find the error on line 4 of `main()` in `myprogram.c`.

However, if the program is complex and generates many function stacks, we may want to trace the calling order of every function stack. We can use `bt` (back trace) to find a series of function calls stack by stack, such as the following example:

```c
/* myprogram.c */
void func() {
    int *a;
    *a = 1;
}

int main() {
    func();
    return 0;
}
```

The error is in `func()`, use `bt` in gdb to see:

```
Open core dump by gdb or coredumpctl.

 . . .

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000055ab058f0135 in func () at myprogram.c:4
(gdb) bt
#0  0x000055ab058f0135 in func () at myprogram.c:4
#1  0x000055ab058f0150 in main () at myprogram.c:8
```

You can see that gdb traces back to the call to `func()`, which is line 8 of `main.c`.