Core dumped, but core file is not in the current directory?

Debugging 'Core dumped' Errors: Finding Your Missing Core File

Uncover the common reasons why a 'core dumped' message appears but the core file is nowhere to be found, and learn how to configure your Linux system to reliably generate and locate these crucial debugging artifacts.

Encountering a 'core dumped' message is often the first step in debugging a crash in a C/C++ application on Linux. A core dump is a snapshot of the process's memory at the time of the crash, invaluable for post-mortem analysis with tools like gdb. However, it's a common frustration to see the 'core dumped' message and then discover that no core file was actually generated in the expected location. This article will guide you through the typical culprits behind missing core files and provide practical steps to ensure they are generated correctly.

Understanding Core Dumps and Their Purpose

When a program crashes due to a fatal error (e.g., segmentation fault, illegal instruction), the operating system can, under certain conditions, create a core dump file. This file contains the memory image of the process, including registers, stack, heap, and loaded libraries. Debuggers use this information to reconstruct the program's state at the moment of the crash, allowing developers to pinpoint the exact line of code and variable values that led to the failure. Without a core file, debugging becomes significantly more challenging, often relying on guesswork or re-running the program with a debugger attached, which isn't always feasible in production environments.

flowchart TD
    A[Program Execution] --> B{Fatal Error Occurs?}
    B -- No --> C[Program Exits Normally]
    B -- Yes --> D{Core Dump Enabled?}
    D -- No --> E[Program Exits, No Core File]
    D -- Yes --> F{Core File Size Limit?}
    F -- Exceeded --> E
    F -- Not Exceeded --> G{Core File Path Configured?}
    G -- No --> H[Core File in CWD]
    G -- Yes --> I[Core File in Configured Path]
    H --> J[Debug with GDB]
    I --> J

Flowchart illustrating the core dump generation process.

Common Reasons for Missing Core Files

Several factors can prevent a core file from being generated or make it appear 'missing'. Understanding these is key to troubleshooting:

1. ulimit -c Setting: The most frequent reason is that the core file size limit is set to 0. This is a per-process resource limit that prevents core files from being written.
2. Permissions: The directory where the core file is supposed to be written might not have the correct write permissions for the user running the crashing process.
3. Disk Space: Insufficient disk space on the filesystem where the core file would be written can prevent its creation.
4. Core Dump Path (/proc/sys/kernel/core_pattern): Linux systems can be configured to write core files to a specific directory and with a specific naming convention, often outside the current working directory (CWD) of the crashing process.
5. Program Exiting Gracefully: If a program catches a signal (like SIGSEGV) and exits gracefully without re-raising the signal or calling abort(), a core dump might not be generated.
6. setuid/setgid Programs: For security reasons, programs running with setuid or setgid bits set typically do not generate core dumps unless specific kernel parameters are configured (/proc/sys/fs/suid_dumpable).

Diagnosing and Resolving Missing Core Files

Let's walk through the steps to diagnose and fix core dump generation issues.

1. Check the Core File Size Limit (ulimit -c)

This is the first place to look. Open a terminal and run ulimit -c. If it returns 0, core dumps are disabled. To enable them for the current shell session, run ulimit -c unlimited or ulimit -c <size_in_KB>. For persistent changes, you'll need to edit /etc/security/limits.conf.

2. Verify Core Dump Pattern and Location

Check the kernel's core dump pattern by running cat /proc/sys/kernel/core_pattern. This file specifies the path and naming convention for core files. If it contains a path like /var/lib/systemd/coredump/core.%p, your core files are being directed there, not your CWD. You can change this pattern temporarily with sudo sh -c 'echo "core" > /proc/sys/kernel/core_pattern' to dump to the CWD, or to a specific directory like sudo sh -c 'echo "/tmp/core.%e.%p" > /proc/sys/kernel/core_pattern'.

3. Check Directory Permissions and Disk Space

Ensure that the user running the crashing program has write permissions to the target core dump directory (either CWD or the one specified by core_pattern). Also, verify that there's enough free disk space using df -h.

4. Test Core Dump Generation

Create a simple C program that intentionally crashes to test your settings. Compile and run it after adjusting ulimit -c and core_pattern.

#include <stdio.h>
#include <stdlib.h>

int main() {
    printf("Crashing program to generate core dump...\n");
    int *ptr = NULL;
    *ptr = 10; // Dereferencing a NULL pointer, causing a segmentation fault
    printf("This line should not be reached.\n");
    return 0;
}

A simple C program designed to cause a segmentation fault and generate a core dump.

Advanced Core Dump Configuration

For more persistent and system-wide core dump management, consider these options:

• /etc/security/limits.conf: To set ulimit -c persistently for specific users or groups, add entries like * soft core unlimited or myuser soft core 102400.
• systemd-coredump: Modern Linux distributions often use systemd-coredump to manage core files, which typically stores them in /var/lib/systemd/coredump. You can configure its behavior via /etc/systemd/coredump.conf.
• sysctl for core_pattern: To make changes to /proc/sys/kernel/core_pattern persistent across reboots, add an entry like kernel.core_pattern = /var/cores/core.%e.%p.%t to /etc/sysctl.conf and apply with sudo sysctl -p.

# Check current core pattern
cat /proc/sys/kernel/core_pattern

# Temporarily set core pattern to current directory
sudo sh -c 'echo "core" > /proc/sys/kernel/core_pattern'

# Temporarily set core pattern to a specific directory with process name and PID
sudo sh -c 'echo "/tmp/cores/core.%e.%p" > /proc/sys/kernel/core_pattern'

# Check ulimit -c
ulimit -c

# Set ulimit -c to unlimited for current session
ulimit -c unlimited

# Example /etc/security/limits.conf entry for user 'myuser'
# myuser soft core unlimited

# Example /etc/sysctl.conf entry for persistent core_pattern
# kernel.core_pattern = /var/cores/core.%e.%p.%t

Command-line examples for checking and configuring core dump settings.

By systematically checking these configurations, you can ensure that your Linux system reliably generates core dump files, transforming a frustrating 'core dumped' message into a valuable debugging opportunity. Remember that a core file is a critical piece of evidence in understanding why your application crashed, so proper configuration is essential for robust software development and maintenance.