About "Core Dump" in Linux
Published: 2021-12-31 09:18:40

##What is core dump

A core dump is a file of a computer’s documented memory of when a program or computer crashed. The file consists of the recorded status of the working memory at an explicit time, usually close to when the system crashed or when the program ended atypically. So a core dump file is very important for program developers since we often need it to locate and fix crash issues. 

##How to activate "core dump"

1. Firstly one can type `ulimit -c` in terminal console, if the output is 0，it means that the "core dump" is deactivated by default. In this case, Linux will not generate core dump file when a program crashes. 

2. Then one can activate "core dump" by setting a non-zero size for generated core dump file by executing `ulimit -c [kbytes]`. For example:

- `ulimit -c 100`：set maximum size of core dump file as 100k
- `ulimit -c unlimited`: no size limit of core dump file



## Configuration of core dump

Once the core dump has been activated, we can get core dump file generated in local  repository. There is still one issue: the core dump file has always the same name as "core" thus it is always over-written if multiple program crashes occur. What if we want to add pid in generated file name, or if we want this file is generated in some other directory?


1. core dump filename with process id

```shell
    echo 1 > /proc/sys/kernel/core_uses_pid
```

Then process id will be attached in file name.

2. One can set the output path and coredump file name pattern by updating sysctl variable "kernel.core_pattern"  in file "/etc/sysctl.conf"
    
Add the following phrase at the end of file sysctl.conf:
    
```shell
     kernel.core_pattern = /var/core/core_%e_%p
```
Save and exit. 

Below are the available options in core_pattern setting:

- **%c** maximum size of the generated file
- **%e** file name
- **%g** group ID of process
- **%h** host name
- **%p** process ID
- **%s** signal which triggered this coredump
- **%t** timestamp of this coredump (number of seconds since 1970-01-01)
- **%u** user ID of the dumped process


Once a modification has been made, one can execute the following command to make it take effect:
```
sysctl –p /etc/sysctl.conf
```

Please note: once we have set /proc/sys/kernel/core_uses_pid as 1，the generated core dump file still has pid in its name even we do not set %p in _core_pattern_.


## Practice

In this section I present a small practice of coredump. Firstly I performed the following configurations (root privilege might be required) for coredump file generation:

```shell
   ulimit -c 1000000
   ulimit -c
   echo 1 > /proc/sys/kernel/core_uses_pid
   echo "/tmp/corefile/core-%e-%p-%t" > /proc/sys/kernel/core_pattern
```
![My settings](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fnxc6c72rrc0f13omqh6.png)


Then let's write some code to provoke a "Segmentation fault".  I put the code lines below into file "testSegmtFault.c ".

```c
#include <stdio.h>

int main()
{
  int IDs[10] = {0,1,2,3,4,5,6,7,8,9};
  int * id_ptr = 0;

  printf("0x%lx: %d \n", (unsigned long)IDs, *IDs);

  // correct logic
  for  (id_ptr=IDs; id_ptr<=(&IDs[9]); id_ptr++)
  {
      printf("0x%lx: %d \n", (unsigned long)id_ptr, *id_ptr);
  }

  // bad logic
  for  (id_ptr=0; id_ptr<=(&IDs[9]); id_ptr++)
  {
      printf("0x%lx: %d \n", (unsigned long)id_ptr, *id_ptr);
  }
}
```

Compile it then execute the generated executable file:
```shell
gcc -g testSegmtFault.c -o seg
./seg
```

Execution output is as follows and there is a Segmentation Fault :D:

```s
qiu@qiu-ThinkCentre-E73:~/workspace/c_basics/linux_flux$ ./seg
0x7ffe283297d0: 0 
0x7ffe283297d0: 0 
0x7ffe283297d4: 1 
0x7ffe283297d8: 2 
0x7ffe283297dc: 3 
0x7ffe283297e0: 4 
0x7ffe283297e4: 5 
0x7ffe283297e8: 6 
0x7ffe283297ec: 7 
0x7ffe283297f0: 8 
0x7ffe283297f4: 9 
Segmentation fault
```

![Crash occurrence:](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7rk5c32yodr67el5c9eg.png)

Now as expected, there is a coredump file named _"core-seg-20017-1639863524"_ generated in `/tmp/corefile/`

Now let's use gdb to debug the crash with help of the executable file and the coredump file:
```sh
cd /tmp/corefile
gdb ~/workspace/c_basics/linux_flux/seg core-seg-20017-1639863524
```
We can see that gdb immediately shows the defective code line number:
![The debug output](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/s3ep8rnnblv409y5hfpb.png)