Analysis and Solutions for Core Dump Generation Failures in Linux Systems

Overview of Core Dump Generation Mechanism

In Linux systems, when an application crashes due to segmentation faults or other critical errors, the operating system can generate a core dump file containing crucial debugging information such as memory images and register states at the time of crash. However, developers often encounter situations where core dump files are not generated as expected. This article analyzes this issue from multiple perspectives and provides systematic solutions.

Working Directory Permission Checks

Core dump files are by default generated in the current working directory of the process. If this directory is not writable, the system cannot create the core file. The following code demonstrates how to check and set directory permissions:

#!/bin/bash
# Check current directory permissions
pwd
ls -la .
# If directory is not writable, try changing permissions
chmod +w .
# Or run the process in a writable directory
cd /tmp
./server

It is important to note that if the application changes effective user ID or group ID through setuid() or setgid() system calls, the working directory must be writable by that user or group. For example, if a server process starts as root and then drops privileges to a regular user, ensure that regular user has write permissions to the working directory.

System Core Dump Configuration

The Linux kernel controls how and where core dumps are generated through the /proc/sys/kernel/core_pattern file. This configuration may redirect core dumps to specific directories or pipe them to handler programs. Use the following command to check current configuration:

cat /proc/sys/kernel/core_pattern

Common configuration patterns include:

• core: Generates a file named core in current directory
• /var/crash/core.%e.%p: Generates file with program name and process ID in /var/crash directory
• |/usr/share/apport/apport %p %s %c: Pipes core dump to handler program

If core_pattern points to a specific directory, ensure that directory exists and is writable by the crashing process. For example, if configured as /var/crash/core, check:

ls -ld /var/crash
# Create directory if it doesn't exist
mkdir -p /var/crash
chmod 1777 /var/crash  # Set sticky bit, allowing all users to write but only delete their own files

Impact of Process Environment Changes

Applications may change working directory, core file size limits, or dumpable flags during execution. The following example shows how processes can modify these attributes:

#include <unistd.h>
#include <sys/resource.h>

int main() {
    // Change working directory
    chdir("/some/other/directory");
    
    // Modify core file size limit
    struct rlimit limit;
    limit.rlim_cur = 0;  // Disable core dumps
    limit.rlim_max = 0;
    setrlimit(RLIMIT_CORE, &limit);
    
    // Modify dumpable flag (privileged processes only)
    prctl(PR_SET_DUMPABLE, 0);
    
    // ... Program logic ...
    return 0;
}

To ensure core dumps can be generated, set appropriate environment through shell script when starting the application:

#!/bin/bash
# Set core file size limit to unlimited
ulimit -c unlimited

# Ensure running in writable directory
cd /tmp

# Run application
./server

Other Possible Causes

In addition to the main reasons above, the following factors may also prevent core dump generation:

• Insufficient filesystem space: Core dump files are typically large, ensure filesystem has enough space
• Existence of core directory: If a subdirectory named core exists in working directory, kernel will not generate core file
• Hard link issues: If a file named core already exists with multiple hard links, kernel will refuse to generate new core file
• SUID/SGID permissions: If executable has SUID or SGID bits set, core dumps are disabled by default
• Thread handling: Older kernel versions may not properly handle core dumps for multi-threaded processes

Testing and Verification

To verify if core dump configuration is effective, use the following testing method:

# Start a test process
sleep 60 &
PID=$!

# Send SIGSEGV signal to simulate segmentation fault
kill -SIGSEGV $PID

# Check if core dump was generated
wait $PID
# If successful, will display "(core dumped)"

# Find core files
find / -name "core*" -o -name "sleep.core*" 2>/dev/null

For systems using systemd, the systemd-coredump package may need to be installed. Core dump files are typically stored in /var/lib/systemd/coredump/ directory in compressed format.

Debugging Techniques

When core dump generation fails, collect debugging information using these methods:

# Check system logs
sudo dmesg | tail -20
sudo journalctl -xe

# Check process limits
cat /proc/$PID/limits | grep -i core

# Check process working directory
ls -l /proc/$PID/cwd

# Check dumpable flag
cat /proc/$PID/status | grep -i dump

Through systematic troubleshooting, most core dump generation issues can be resolved. The key is understanding the multi-layered control of Linux core dump mechanism: from process-level resource limits, to system-level core pattern configuration, to filesystem permission constraints.