A core dump is a snapshot of a program’s memory at the time of a crash, used to analyze errors like segmentation faults. 1. It includes executable code, stack/heap memory, CPU registers, and thread states. 2. Core dumps are not always enabled by default; configure ulimit and /proc/sys/kernel/core_pattern. 3. Tools like GDB allow loading the binary and core dump to trace the crash using commands like bt, info registers, and thread apply all bt. 4. Best practices include compiling with debug symbols, retaining the matching binary, checking logs, and automating secure storage in production environments.

A core dump is essentially a snapshot of a program's memory at the moment it crashes. It's like freezing the state of the application right when something goes wrong, which can be super useful for figuring out why things went south.

If you're dealing with software issues — especially in production or during development — knowing how to analyze a core dump can save you hours of guesswork.

What Exactly Happens During a Core Dump?

When a program crashes due to an error like a segmentation fault, the operating system can be configured to write all the current contents of memory into a file. This includes:

• The program’s executable code
• Stack and heap memory
• CPU registers
• Thread states

This file is your core dump. By default, it might just be called core or include extra info like the PID or timestamp (depending on system settings).

It's not always enabled by default, though. You may need to adjust the ulimit setting to allow large enough files and make sure /proc/sys/kernel/core_pattern is set up the way you want it (like where to save dumps and how to name them).

Tools You Can Use to Analyze Core Dumps

There are a few go-to tools depending on what kind of program you’re debugging.

The most common one is GDB (GNU Debugger). If you have the original binary and the core dump file, you can load both into GDB:

gdb /path/to/your/program /path/to/core

Once loaded, GDB will show you where the crash happened — like which function was being executed or which line of code triggered the issue. Useful commands inside GDB include:

• bt – shows the backtrace (call stack)
• info registers – shows CPU register values at crash time
• thread apply all bt – if multi-threaded, shows each thread's stack

Other tools like crash, lldb, or even specialized profilers can also work, especially in more complex environments like kernel panics or embedded systems.

How to Get the Most Out of Your Analysis

Just having a core dump isn't always enough. Here are some tips to make the analysis smoother:

• Compile with debug symbols: If you compiled your app without -g, GDB won’t know variable names or exact source lines. Always build with debug info for development versions.
• Keep the matching binary around: A core dump is only useful if you have the exact same version of the binary that generated it.
• Use symbolic links or versioning: So you don’t lose track of which binaries match which dumps.
• Check logs too: Sometimes the last few log messages before the crash give context that the dump alone won’t show.

Also, in server environments or cloud setups, consider automating upload and storage of core dumps — but keep privacy and security in mind.

That’s basically it. Core dumps aren’t flashy, but they’re powerful when used right. Just remember: no debug symbols = limited insight, and no matching binary = wasted file. Keep those two things close, and you’ll be debugging like a pro.

The above is the detailed content of What is a core dump and how can it be analyzed?. For more information, please follow other related articles on the PHP Chinese website!