Understanding and Analyzing Linux Core Dumps with GDB

1. Introduction to Core Dump

In Linux system development, a core dump is an essential tool that captures the program's memory image, registers, and execution state at the moment of an abnormal termination such as segmentation fault or illegal instruction, providing a “snapshot” for post‑mortem analysis.

2. Core Dump Generation Mechanism

2.1 Trigger Conditions

Core dumps are produced when a process receives signals like SIGSEGV, SIGABRT, or SIGFPE and does not handle them. Examples include dereferencing a null pointer, accessing out‑of‑bounds memory, or invoking abort() after an assertion failure.

2.2 Configuration Points

By default, the kernel limits core file size to zero. Use ulimit -c unlimited to allow unlimited core files. Ensure the working directory is writable, adjust /proc/sys/fs/suid_dumpable for set‑uid programs, and customize the core file naming pattern via /proc/sys/kernel/core_pattern .

3. Common Culprits of Core Dumps

3.1 Pointer Errors

Null pointers, wild pointers, and dangling pointers are frequent sources of crashes. Example of a null‑pointer dereference:

#include
int main() {
    int *ptr = NULL;
    *ptr = 10; // triggers core dump
    return 0;
}

Example of a wild pointer:

#include
#include
int main() {
    int *ptr;
    *ptr = 10; // undefined behavior
    free(ptr);
    ptr = NULL;
    return 0;
}

Example of a dangling pointer:

#include
#include
int main() {
    int *ptr = (int *)malloc(sizeof(int));
    *ptr = 10;
    free(ptr);
    *ptr = 20; // use after free
    return 0;
}

3.2 Array and Pointer Out‑of‑Bounds

Accessing an array beyond its declared size or moving a pointer outside its allocated region also causes core dumps. Sample code that overruns a six‑element array:

#include
int main() {
    int i;
    int array[6];
    for (i = 0; i < 8; i++) {
        array[i] = 0; // out‑of‑bounds write
        printf("Grayson Zheng\n");
    }
    return 0;
}

3.3 Data Races and Non‑Standard Code

In multithreaded programs, unsynchronized access to shared data can lead to race conditions that corrupt memory and trigger core dumps. Additionally, passing invalid arguments to functions or violating API contracts may cause illegal memory accesses.

4. Practical Core Dump Analysis with GDB

4.1 Enabling Core Dumps

Check the current limit with ulimit -c . Setting ulimit -c unlimited removes the size restriction. Adjust /proc/sys/kernel/core_pattern to store cores in /tmp/ with a descriptive name, e.g., /tmp/core-%e-%s-%u-%g-%p-%t .

4.2 Generating Core Dumps

Two simple C programs illustrate core dump creation: one crashes via a null‑pointer dereference, the other is terminated with kill -11 (SIGSEGV) after running.

#include
void func(){
    int *p = NULL;
    *p = 13;
}
int main(){
    func();
    return 0;
}

#include
#include
int global_num;
int main(){
    while(1){
        printf("global_num = %d\n", global_num++);
        sleep(1);
    }
    return 0;
}

4.3 Loading a Core Dump in GDB

Run gdb . Useful commands include:

bt (or where ) – shows the call stack.

p – prints variable values.

info registers – displays CPU register contents at the crash point.

5. In‑Depth Case Studies

5.1 Simple Example

A minimal program that dereferences a null pointer is compiled with -g , executed to produce a core file, and then examined with GDB. The backtrace reveals the crash location, and p ptr confirms the pointer is NULL.

5.2 Complex Multithreaded Scenario

A program creates a writer and a reader thread that share an array protected by a mutex. Occasionally the reader accesses the array out of bounds, causing a core dump. Using info threads to list threads, thread 2 to switch to the reader, and bt to view the stack, the out‑of‑range index is identified, explaining the crash.

6. Full‑Article Summary

Core dump analysis is a critical skill for Linux developers. Understanding how core files are generated, configuring the system to produce them, and mastering GDB commands such as bt , p , and info registers enable rapid identification of bugs like null‑pointer dereferences, array overflows, and multithreaded race conditions.

Beyond GDB, tools like Valgrind and perf complement core‑dump analysis by detecting memory leaks and performance bottlenecks. Combining these techniques leads to more robust, reliable software.