Understanding Core Dumps and Debugging Techniques with GDB

1. Definition and Classification of Program Core

Program core refers to the crash behavior when an application cannot maintain a normal running state, generating a core‑dump file that records memory, processor, registers, program counter, stack pointer, and other state information for post‑mortem analysis.

The core causes are classified into three categories: machine, resource, and program bugs.

2. Function Stack Introduction

When opening a core file, the first focus is the function call stack at the crash point. This section briefly introduces the function stack.

2.1 Register Introduction

Only 64‑bit registers are covered. Important registers include %rsp (stack top), %rbp (stack base), and argument registers %rdi, %rsi, %rdx, %rcx, %r8, %r9.

2.2 Function Call

2.2.1 Call Stack Frame

During a function call, arguments are pushed onto the stack (in reverse order), followed by the return address, which points to the next instruction after the call.

2.2.2 Called Function Stack Frame

The called function saves the caller's %rbp, then saves callee‑saved registers, and allocates space for local variables.

2.3 Summary

The function stack is a delicate structure; any improper memory access can cause program crashes.

3. GDB Core定位 (Core Localization with GDB)

3.1 Core Files

Check "/proc/sys/kernel/core_pattern" to determine core file generation rules.

3.2 Variable Printing

Common commands for printing variables in GDB:

print [Expression]
print $[Previous value number]
print {[Type]}[Address]
print [First element]@[Element count]
print /[Format] [Expression]

Format specifiers: o (octal), x (hex), u (unsigned decimal), t (binary), f (float), a (address), c (char), s (string).

3.2.2 x Command

x /

3.2.3 Container Object Printing

Example for printing a binary std::string:

# Convert _M_p to _Rep pointer and offset one struct size
p *((std::string::_Rep*)(s._M_dataplus._M_p) - 1)

Then print the string data:

# n is _Rep._M_length
x /ncb s._M_dataplus._M_p

3.2.4 Memory Dump

dump [format] memory filename start_addr end_addr
dump [format] value filename expr

3.3 Locating Code Lines

Use GDB's backtrace, display, and addr2line to map addresses to source lines. If optimization interferes, recompile with -O0.

# Jump to frame 20
frame 20
# Show program counter
display /i $rip
# Convert address to source line
shell /opt/compiler/gcc-8.2/bin/addr2line -e bin address

3.3.3 Stack Repair

-----------------------------------
Low addresses
-----------------------------------
0(%rsp)  | top of the stack frame
-n(%rbp) | variable sized stack frame
-8(%rbp) | varied
0(%rbp)  | previous stack frame address
8(%rbp)  | return address
-----------------------------------
High addresses

3.4 Locating Core Reasons

Identify the signal (e.g., SIGBUS) and examine the offending assembly instruction using "layout asm".

Example of a null‑pointer crash:

int main(int argc, char* argv[]) {
    int* a = nullptr;
    *a = 1;
    return *a;
}

Assembly shows the fault at movl $0x1, (%rax) , where %rax holds a null address.

3.4.5 Abnormal Function Address Inspection

When virtual function tables are corrupted, the crash may occur at a call like mov (%rax), %rax . Inspect the vtable pointers to find the mismatch.

Summary of Core Localization Steps

Determine the general cause of the core (machine vs. program).

Locate the offending source line.

Identify the exact instruction executed.

Examine the variables involved for incorrect values.

Effective use of assembly inspection and GDB printing commands (x, print, display) greatly aids core analysis.

References

Assembly inspection tools: godbolt.org , cppinsights.io

Official GDB documentation: sourceware.org/gdb