Where Do I Find Core Dump in Linux, and Master How Do I View and Analyze the Backtrace (Stack Trace 2026)

If you’ve ever written a C, C++, Python, Java, or even a system-level application in Linux, chances are you’ve heard the term core dump. And if you’re reading this, you’ve probably also run into a frustrating crash where your program simply vanished with a cryptic message like Segmentation fault (core dumped).

What Exactly Is a Core Dump in Linux?

Let’s keep this simple.

A core dump in Linux is a snapshot of your program’s memory at the exact moment it crashed.

Think of it like taking a picture of a crime scene.
You get:

• The values of variables
• The state of the stack
• The content of memory
• The instruction pointer location
• Which function called which (stack trace)
• And why the crash happened

This is extremely useful for debugging crashes that are hard to reproduce.

Developers use core dumps to figure out:

• segmentation faults
• illegal memory access
• null pointer dereferences
• stack corruption
• out-of-bounds access
• runtime exceptions

If you ever wondered why your program crashed, the core dump is your truth-teller.

How to Check if Core Dump Is Enabled in Linux

Before you can view or analyze core dumps, you must check whether they’re even enabled.

Run:

ulimit -c

You’ll get one of two results:

0 → Core dumps are disabled

This is the most common default.

Unlimited → Core dumps are enabled

This means the system will generate a core dump whenever an application crashes.

How to Enable Core Dump in Linux (Temporary & Permanent Methods)

If ulimit -c returns 0, your system won’t generate core files.

Let’s fix that.

1. Enable Core Dump Temporarily (For Current Session)

Use:

ulimit -c unlimited

To verify:

ulimit -c

Now it should show:

unlimited

This lasts only for the current terminal session.

2. Enable Core Dump Permanently (System-Wide)

Edit /etc/security/limits.conf

Add these lines:

* soft core unlimited
* hard core unlimited

This ensures core dumps remain enabled for all users.

3. Set Core Dump File Location and Format

Linux stores core files based on kernel.core_pattern.

Check its current value:

cat /proc/sys/kernel/core_pattern

You might see something like:

core

or

core.%e.%p.%t

or even:

|/usr/share/apport/apport %p %s %c %P %u %g %t %e

To store core dumps in a specific location, set:

sudo bash -c 'echo "/var/core/core.%e.%p" > /proc/sys/kernel/core_pattern'

This creates files like:

core.myapp.1234

Now you know exactly where to find them.

Where to Find the Core Dump in Linux

This depends on three things:

1. Whether core dumps are enabled
2. The value of kernel.core_pattern
3. Your current working directory

Here are the most common locations:

1. The same directory from where the program was executed

Example:

./myprogram
Segmentation fault (core dumped)

You might get:

core

2. /var/core/ directory (if configured by admin)

Check using:

ls /var/core/

3. Custom directory defined by your core_pattern

Example:

/tmp/core.%e.%p

4. Systemd-coredump service (Arch Linux, Fedora, Ubuntu newer versions)

If you’re using Arch Linux, Fedora, or any distro using systemd, core dumps may not appear as files at all.

Instead, they are stored in the system journal.

Check them with:

coredumpctl list

To extract:

coredumpctl dump > core.dump

Or analyze directly:

coredumpctl gdb

This is why many people struggle finding core dump in Arch Linux—systemd stores them differently.

How to Generate Core Dump in Linux (Manually)

Sometimes your program won’t crash automatically, but you still want a core dump.

Use this command:

gcore <PID>

Example:

gcore 1532

This creates:

core.1532

This is the easiest command to generate core dump in Linux.

How to Collect Core Dump in Linux

If you’re debugging servers or background processes, use:

kill -SIGSEGV <PID>

This forces the program to crash and generate a core dump.

How to Read Core Dump in Linux

To read a core dump, we use:

GDB — the GNU Debugger

Install it:

sudo apt install gdb

or on Arch:

sudo pacman -S gdb

GDB Core Dump Analysis in Linux: Step-by-Step

Run:

gdb <executable> <core-file>

Example:

gdb ./myapp core.1234

GDB will open and show the reason for the crash.

Then type:

bt

This gives the backtrace (stack trace).

You’ll see something like:

#0  0x00007ffff7a543d7 in strcpy () from /lib64/libc.so.6
#1  0x000000000040113d in main () at main.c:12

This tells you:

• exact line number where crash happened
• which function caused it
• how the call chain reached there

This is the heart of core dump Linux analysis.

Read Full Tutorial about GDB here : GDB GNU Debugger

Understanding the Backtrace (Stack Trace)

Let’s decode what the backtrace is telling you.

Every line usually shows:

#frame_number  memory_address in function_name (args) at file:line

Example Breakdown

#0  0x00007ffff7a543d7 in strcpy () from /lib64/libc.so.6

Meaning:

• Frame #0 → This is where the crash occurred
• strcpy() → Crashed inside a standard library function
• You passed invalid memory to strcpy → likely a buffer overflow

Next line:

#1  0x000000000040113d in main () at main.c:12

This tells you your own app called strcpy in a wrong way at line 12.

This gives you a clear direction to fix the crash.

How to Analyse Core Dump in Linux Using GDB (Deeper Walkthrough)

Inside GDB, here are essential commands:

1. Print the crash reason

info signals

2. Print local variables

info locals

3. Print function arguments

info args

4. Move up and down stack frames

up
down

5. Print a variable

print var

6. Disassemble crashing function

disassemble

7. Show source code

list

This is the core of crash dump analysis in Linux.

Memory Dump Analyzer Linux Tools (Extra Useful Tools)

Other than GDB, Linux developers often use:

1. valgrind

To detect memory corruption.

valgrind ./myapp

2. addr2line

Convert addresses to line numbers.

addr2line -e myapp 0x40113d

3. readelf / objdump

View symbol tables.

4. systemd-coredump (Arch, Fedora)

Handles central core dump storage.

Common Reasons Why Core Dump Is Not Generated

If you can’t find a core dump, check:

1. ulimit -c is 0

Core dumps disabled.

2. Application is setuid

Linux blocks core dumps for security.

3. No write permission

Directory not writable.

4. systemd storing core dumps

Run:

coredumpctl list

5. core_pattern is piped

Example:

|/usr/share/apport/apport %p %s %c %P %u %g %t %e

Means it’s handled by a crash reporter.

Full Example: From Crash to Debugging

Let’s say your C program crashes with:

Segmentation fault (core dumped)

Step 1: Check for core dump

ls core*

Step 2: Open in GDB

gdb ./a.out core

Step 3: View backtrace

bt

Output:

#0  main.c:14

Step 4: Inspect variables

info locals

You’ll immediately see the reason.

This is the simplest form of core dump in Linux debugging.

Core Dump on Arch Linux

Since many Arch Linux users ask specifically about this:

• Arch uses systemd-coredump
• Core files are stored in journal, not filesystem

Check:

coredumpctl list

Analyze:

coredumpctl gdb

This is why many newcomers can’t find the actual core file in Arch Linux.

Commands Summary (Quick Cheat Sheet)

Check if core dumps are enabled

ulimit -c

Enable core dumps

ulimit -c unlimited

Set core dump location

echo "/var/core/core.%e.%p" | sudo tee /proc/sys/kernel/core_pattern

Force a core dump

gcore <PID>

Analyze using GDB

gdb <exe> <core>
bt

Arch Linux

coredumpctl list
coredumpctl gdb

Why Every Developer Should Know Core Dumps

Whether you’re a beginner or an experienced engineer, knowing how to analyze core dump in Linux gives you superpowers.

Core dumps help you:

• Debug crashes even when you can’t reproduce them
• Understand memory corruption
• Debug server crashes after the fact
• Reverse-engineer program behavior
• Fix production bugs quickly

It’s one of the most important skills in systems programming.

Below is a complete real-world C++ example where we:

1. Write a buggy C++ program
2. Compile it
3. Enable + generate a core dump
4. Analyze the core dump using GDB (step-by-step)
5. Show the exact backtrace + explanation

1. C++ Program That Intentionally Crashes (Bug Inside)

Save this file as: crash.cpp

#include <iostream>
#include <cstring>

void copyString(const char* src) {
    char buffer[5];  // BUG: buffer too small
    std::strcpy(buffer, src);  // This will overflow
    std::cout << "Copied: " << buffer << std::endl;
}

int main() {
    const char* text = "HelloWorld";  // 10 characters → overflow
    copyString(text);
    return 0;
}

Why this crashes?

buffer can hold only 5 bytes, but HelloWorld is 10 bytes, causing a buffer overflow → segmentation fault → core dumped.

2. Compile the Program (with debug symbols)

g++ -g crash.cpp -o crash

-g is important — it helps GDB show exact line numbers.

3. Enable Core Dump in Linux

Check first:

ulimit -c

If result is 0, enable core dump:

ulimit -c unlimited

4. Run the Program to Generate Core Dump

./crash

You will get:

Segmentation fault (core dumped)

Now list core file:

ls -l core*

You may see:

core

or

core.12345

5. Analyze the Core Dump Using GDB

Run:

gdb ./crash core

Now GDB opens the crash snapshot.

6. Get the Stack Trace (Backtrace)

Inside gdb, type:

bt

You will see output similar to:

#0  0x00007ffff7a543d7 in __strcpy_sse2_unaligned () from /lib64/libc.so.6
#1  0x0000000000401178 in copyString (src=0x400804 "HelloWorld") at crash.cpp:7
#2  0x000000000040119f in main () at crash.cpp:13

7. Understanding the Backtrace (Line-by-Line Analysis)

Let’s break this down like a human:

Frame #0

#0  __strcpy_sse2_unaligned

This tells us the actual crash happened inside the C library’s strcpy() function.

strcpy() crashed because it tried writing beyond buffer limits.

Frame #1

copyString (src="HelloWorld") at crash.cpp:7

Line 7 in crash.cpp:

std::strcpy(buffer, src);

This is the exact buggy line.

Frame #2

main () at crash.cpp:13

Line 13:

copyString(text);

This shows the call chain:

main → copyString → strcpy → crash

This is the exact purpose of core dump analysis in Linux — finding how and where your program died.

8. Inspect Variables at Time of Crash

Inside gdb:

See local variables:

info locals

You may see:

buffer = "Hello"   (truncated)
src = 0x400804 "HelloWorld"

This tells you:

• buffer was too small
• src was a long string
• strcpy overflowed and crashed

9. Inspect Function Arguments

info args

Output:

src = 0x400804 "HelloWorld"

Perfect — now you know what was passed to the crashing function.

10. View the Source Code in GDB

list

You’ll see the source around the crash location.

Final Crash Explanation (Human-Friendly)

Your C++ program crashed because:

• You created a tiny 5-byte buffer
• You used strcpy which does no size-checking
• You copied a 10-byte string
• Memory overflowed → segmentation fault
• Linux created a core dump
• GDB helped you view the exact line that caused the crash

This is exactly how developers perform core dump analysis in Linux.

FAQ: Core Dump in Linux

1. What is a core dump in Linux, and why is it created?

A core dump in Linux is a snapshot of a program’s memory at the exact moment it crashes.
It helps developers understand what went wrong—like a crime-scene photo of your software.

The core file contains:

• Registers
• Stack memory
• Heap memory
• Function call history (backtrace)
• Values of variables

This is why crash dump analysis in Linux is essential while debugging segmentation faults, buffer overflows, or memory corruption bugs.

2. How do I check if core dump is enabled in Linux?

You can verify this using:

ulimit -c

• If you see 0, core dumps are disabled.
• If you see unlimited, core dumps are enabled.

This is the simplest way for how to check if core dump is enabled in Linux.

3. How do I enable core dump in Linux permanently?

To enable core dump in Linux, you can either do it temporarily or permanently.

For permanent enablement, edit:

/etc/security/limits.conf

Add:

* soft core unlimited
* hard core unlimited

Then configure where the system stores core files:

echo "/var/core/core.%e.%p" | sudo tee /proc/sys/kernel/core_pattern

Now core dumps will always be generated and saved predictably.

4. Where do I find the core dump in Linux?

Core dumps may appear in different places depending on settings.

Common locations:

1. Current working directory (core or core.PID)
2. /var/core (if configured with core_pattern)
3. /tmp
4. Using systemd-coredumpctl on modern distros like Arch Linux, Fedora, Ubuntu

If you use Arch, the core file will not appear on disk. Instead, use:

coredumpctl list

This is why people struggle with core dump Arch Linux behavior.

5. How do I read a core dump in Linux?

You use the GDB debugger.

Example:

gdb ./myapp core

Then get the backtrace:

bt

This shows:

• where the crash occurred
• which function caused it
• the entire call stack

This is called gdb core dump analysis in Linux, the standard method used by professionals.

6. How do I analyze core dump in Linux using GDB step-by-step?

Here’s the exact workflow for how to analyse core dump in Linux using gdb:

gdb <executable> <core-file>

Inside GDB:

• bt → backtrace
• info locals → local variables
• info args → function arguments
• list → show source code
• up / down → navigate stack frames

This shows you the exact line and variable values that caused the crash.

7. What is the command to generate core dump in Linux manually?

Use:

gcore <PID>

This is the official command to generate core dump in Linux without crashing the program.

Useful for:

• debugging stuck processes
• analyzing deadlocks
• freezing memory state for investigation

8. How do I collect core dump in Linux for a background or server process?

You can force a core dump with:

kill -SIGSEGV <PID>

Or use:

gcore <PID>

This is the answer to how to collect core dump in Linux when dealing with server applications or daemons.

9. How do I check core dump patterns and storage settings?

Run:

cat /proc/sys/kernel/core_pattern

This shows:

• the naming format
• whether a crash reporter is intercepting dumps
• whether the system is piping the core dump to systemd

If you see something starting with |, then Linux is piping core dumps to a program.
This is common in Ubuntu and Arch Linux with systemd-coredump.10. Why does Linux sometimes not generate core dumps?

Some common reasons:

• ulimit -c is 0
• Application is setuid (security restriction)
• Directory has no write permission
• Systemd captures core dumps instead of writing files
• App is running inside a container (needs special config)

Fixing these ensures how to get core dump in Linux always works.

11. How to do memory dump analysis in Linux?

Aside from GDB, Linux developers often use:

Useful Tools:

• valgrind → memory corruption detection
• addr2line → convert crash addresses to code lines
• objdump → disassembly
• readelf → ELF structure
• systemd-coredumpctl → manage dumps in Arch/Ubuntu

All these help with memory dump analyzer Linux workflows.

12. What is core dump Linux analysis and why is it important?

Core dump Linux analysis is the process of:

1. Opening the core file
2. Recreating program state at crash time
3. Viewing the backtrace
4. Inspecting variables
5. Understanding memory state

It is essential for:

• debugging production crashes
• diagnosing segmentation faults
• analyzing memory corruption
• ensuring software stability

This is the main reason companies heavily rely on core dump analysis in Linux before shipping products.

13. How do I generate a core dump in Linux for testing?

If you want to practice:

echo "test" > /dev/null
kill -SIGSEGV $$

Or write a simple C/C++ program that intentionally crashes.

This helps beginners learn how to generate core dump in Linux safely.

14. Does Arch Linux handle core dumps differently?

Yes.
Arch Linux uses systemd-coredump, which stores dumps in the journal instead of writing core files on disk.

View stored dumps:

coredumpctl list

Analyze directly with:

coredumpctl gdb

This is the standard workflow for core dump Arch Linux users.

15. How do I get the stack trace from a core dump in Linux?

You simply open the core dump using GDB:

gdb ./a.out core

Then:

bt

This prints the backtrace, which includes:

• crash location
• call chain
• function order
• line numbers

Backtrace = the heart of how to analyze core dump in linux.

16. How do I fix “Segmentation fault (core dumped)” errors?

You fix them by:

• enabling core dumps
• analyzing the core file
• identifying buffer overflow or illegal memory access
• correcting logic errors in your C/C++ code

Using a core dump in Linux is the cleanest way to find the exact cause of a segmentation fault.

17. What is the best way for beginners to learn core dump debugging?

Start simple:

1. Write a small C/C++ program
2. Cause a segmentation fault
3. Enable core dump
4. Analyze using GDB
5. Understand the backtrace step-by-step

This hands-on approach teaches everything from how to read core dump in linux to gdb core dump analysis in linux.