Analyzing Application Crashes with coredumpctl

Version 1.0 Last review: 2026

Introduction

When an application crashes on Fedora, the system may store a core dump. A core dump is a snapshot of the memory of the crashed process at the time of the failure.

Fedora uses systemd-coredump to capture crash data. The command line utility coredumpctl provides access to these crash records.

Using coredumpctl, you can:

list recorded crashes
inspect metadata about a crash
export the stored core dump
open the dump directly in gdb
generate a backtrace suitable for bug reports

This document explains how Fedora Quality testers and users can retrieve useful debugging information from application crashes.

Prerequisites

Before you begin, ensure that:

you have gdb installed (sudo dnf install gdb)
the crash occurred on a Fedora system
the crash occurred recently, i.e. it has not been yet cleaned up by the system

Listing recorded crashes

To list all recorded crashes:

coredumpctl list

Example output:

TIME                           PID  UID  GID SIG     COREFILE EXE                     SIZE
Thu 2025-11-13 09:50:10 CET   5341 1000 1000 SIGABRT missing  /usr/bin/gnome-shell       -
Thu 2025-12-18 23:15:51 CET   5238 1000 1000 SIGABRT present  /usr/bin/gnome-software  50M

The most relevant columns are:

TIME – time when the crash occurred
PID – process ID of the crashed application
COREFILE – whether the dump is still available
EXE – executable that crashed

The COREFILE column is import - you mostly care about present (available for analysis), missing (already cleaned up) and inaccessible (occurred under a different user, see Troubleshooting). Full description is in man coredumpctl.

Filtering results

You can filter crashes by application name (or full EXE path):

coredumpctl list gnome-software

To list crashes starting from a specific time:

coredumpctl list --since "2026-02-16 13:00:00"

Inspecting crash details

To inspect metadata for a specific crash:

coredumpctl info <PID>

Check that the following information matches the crash you want to analyze:

executable (EXE)
command line
timestamp

If the core dump has already been removed, this metadata can still help identify the issue.

As process IDs can be reused it may not be enough to rely on the PID itself to identify a core dump fully - several crashes may share the same PID. If that’s the case (coredumpctl info <PID> shows you several matching crashes), you can use further filtering options to specify the exact one you’re interested in.

First list all the matching crashes:

coredumpctl list <PID>

Then use the timestamp from the list output to narrow down the match (use the original timestamp for --since and e.g. add one second to the timestamp in --until):

coredumpctl info --since <timestamp> --until <timestamp> <PID>

Exporting the core dump

Core dumps are stored internally by systemd-coredump. If they haven’t been cleaned up yet, you can export them to a file:

coredumpctl dump <PID> -o core.<PID>

As described in the previous section, there might be several crash matches for the chosen PID. coredumpctl dump always exports the latest one. If that’s not what you want, use the same filtering options as described previously to specify an exact match.

Verify that the file was created:

ls -lh core.<PID>

Core dumps can be large. Compress them before sharing, they usually compress really well.

xz core.<PID>

Core dumps contain process memory and may include sensitive information such as passwords, tokens, cookies, or fragments of documents. Do not upload them to public locations unless you are certain they do not contain sensitive data.

Generating a backtrace

Developers often require a backtrace instead of the full core dump. A backtrace is a list of function calls that shows what the program was doing at the moment it crashed. In coredumpctl, it helps you see the path through the code that led to the crash, with the most recent call usually near the top. To open the crash in gdb:

coredumpctl debug <PID>

gdb may prompt you to enable debuginfod. This service automatically downloads debugging symbols required for the analysis. Downloaded symbols are stored in ~/.cache/debuginfod_client/.

This directory can grow over time and may be safely cleaned if needed.

Generating the backtrace in gdb

In order to generate the backtrace and also save it as backtrace.<PID>.txt, run the following commands inside gdb:

set pagination off
set logging file backtrace.<PID>.txt
set logging on
thread apply all backtrace full
quit

Troubleshooting

Simulating a crash

If there is no crash marked as present listed by coredumpctl, but you still want to get familiar with this crash debugging guide, you can simulate a fake crash by yourself:

Start a command or application in the background (appending & to the end of the command). In this example, we use a simple sleep command:

sleep 3600 &
pid=$!

The $! variable contains the process ID (PID) of the command you have just started. Use it to send an ABRT signal ("abnormal termination") to that process:

kill -ABRT $pid

This will make the process stop uncleanly and the systemd-coredump should catch and record the crash.

sleep is a very small and simple application, and the resulting traceback will be very short. If you try this with e.g. some graphical application, the traceback (and the whole debugging process) will be much longer.

Core dump doesn’t get saved

Sometimes an application crash does not produce a core dump. Common causes include:

Application did not terminate with a crash signal

Core dumps are typically generated when a process receives signals such as:

SIGSEGV
SIGABRT

If the application handles the error internally, a dump may not be created.

Core dumps are disabled

Check the current limit:

ulimit -c

If the value is 0, core dumps are disabled. Temporarily enable them (until reboot):

sudo ulimit -c unlimited

Permanent limits can be configured in /etc/security/limits.conf.

systemd-coredump storage limits

The coredumps might not be processed or stored when they are too large. You can inspect the current limits and configure them, see:

man coredump.conf

'Permission denied' when generating a backtrace

Core dumps belong to the user that started the application. If you see core dumps marked as inaccessible, or get Failed to open, Permission denied or similar errors when running coredumpctl debug, you’re likely trying to access a core dump which is owned by a different user (for system services, that is often the root). You can inspect who owns the core dump with coredumpctl info <PID>, see the UID (user ID) value. Either switch to that user, or if you have admin access, run the commands with sudo (sudo coredumpctl debug <PID>).

Reporting crashes

When reporting a crash, include the following information whenever possible:

Backtrace of all threads. See Generating a backtrace.
Package version:
```
rpm -q <package>
```
Fedora version:
```
cat /etc/os-release
```
Reproduction steps that explain how the crash occurred.
Attach the full core dump only if developers explicitly request it.

For more information on how to report bugs, refer to How to file a bug.

Additional information

Manual pages:

man coredumpctl
man systemd-coredump
man coredump.conf

These documents provide detailed information about configuration and advanced usage.

Related guides:

Stack Traces | GNOME - includes instructions for debugging Flatpak applications

Want to help? Learn how to contribute to Fedora Docs ›