Extract an Apport Crash Report into Inspectable Files

apport-unpack splits an Apport problem report into one file per field, including any core dump, so you can inspect each piece on its own. The examples use the apport 2.28.3-0ubuntu0.1 package installed on this machine. Allow about five minutes for a straightforward extraction, plus time to actually inspect what comes out.

Before you start

You need an existing Apport report, a writable destination, and the apport-unpack command. The input can be a normal report file, one whose name ends in .gz, or standard input. You do not normally need elevated privileges: reach for sudo only when the report cannot be read or the destination cannot be written by your account.

Apport reports can hold sensitive material. Fields such as ProcEnviron, ProcCmdline, ProcCwd, memory mappings and a core dump may reveal credentials, paths or application data. Work in a directory with suitable permissions, and do not upload the extracted directory just because it happens to be convenient.

1. Find a report and check the command

First pin down the exact report you intend to read. Crash reports are commonly kept in /var/crash, but the path and access permissions depend on how the report was created and managed.

$ command -v apport-unpack
/usr/bin/apport-unpack
$ find /var/crash -maxdepth 1 -type f -name '*.crash' -print

If find throws a permission error, or the report is not readable, stop and decide deliberately whether it should be handled with elevated privileges. Do not make a broad copy of /var/crash just to get around one unreadable file.

2. Choose a new or empty destination

The destination must either not exist or be empty. Use a dedicated directory, so the extracted fields cannot be confused with anything already there:

$ report=/var/crash/REPORT.crash
$ out=/tmp/apport-report-fields
$ mkdir "$out"
$ test -r "$report" && test -w "$out" && echo "ready"
ready

Swap in the real path for /var/crash/REPORT.crash. If the directory already holds anything, pick another path rather than deleting files automatically: the command refuses a non-empty directory outright and will not overwrite it for you.

3. Unpack the report

Run the extraction as your ordinary user once the checks above pass:

$ apport-unpack "$report" "$out"
$ find "$out" -maxdepth 1 -type f -printf '%f %s bytes\n' | sort | head
Architecture 5 bytes
CoreDump 311296 bytes
Date 24 bytes
Dependencies 365 bytes
DistroRelease 12 bytes
ExecutablePath 20 bytes
ExecutableTimestamp 10 bytes
Package 23 bytes
PackageArchitecture 5 bytes
ProblemType 5 bytes

Each report key becomes a file named after that key. Text values come out as UTF-8, binary values stay binary, so reach for file or sha256sum instead of opening every field in a terminal. A field is not human-readable just because its filename looks tidy.

Checkpoint: confirm the extraction

Check the directory holds the fields you expected, and that a large field has a plausible size:

$ test -s "$out/ExecutablePath" && cat "$out/ExecutablePath"
/usr/bin/example-program
$ test -e "$out/CoreDump" && stat --printf='%n: %s bytes\n' "$out/CoreDump"
/tmp/apport-report-fields/CoreDump: 311296 bytes

Exact filenames and sizes vary by report. Some reports carry no core dump at all, and some fields may simply be absent. An empty result, or an error before any files appear, usually means the input was missing, unreadable or malformed.

4. Read from standard input when needed

Use a single hyphen as the report argument when another command supplies the report. Handy in a pipeline, but remember the current implementation loads standard input in one go, so do not feed it an unexpectedly huge stream:

$ out=/tmp/apport-stdin-fields
$ mkdir "$out"
$ cat /var/crash/REPORT.crash | apport-unpack - "$out"
$ test -f "$out/ProblemType" && sed -n '1p' "$out/ProblemType"
Crash

Do not use a pipeline just to obscure which report is being processed. Keep the input path, or the command that produced it, somewhere in your notes, especially when comparing two incidents side by side.

5. Handle compressed reports

When the report filename ends in .gz, this installed version opens it as gzip input automatically. The destination rules do not change:

$ report=/path/to/REPORT.crash.gz
$ out=/tmp/apport-gzip-fields
$ mkdir "$out"
$ apport-unpack "$report" "$out"
$ test -f "$out/Date" && echo "gzip report extracted"
gzip report extracted

If a file is compressed but lacks the .gz suffix, do not assume it will still be detected from its contents. Verify the filename and format first, then run an explicit decompression step into a controlled stream if you need to.

Common failures and safe recovery

Destination directory exists and is not empty. means the safety check did its job. Inspect the directory, keep anything useful, and rerun against a freshly created empty one: this also stops fields from two different reports getting mixed together.

A permission error is a different animal from a report-format error. Grant access only to the specific report or destination, or run the command with sudo while keeping the output directory locked down. If you do reach for sudo, the extracted files may end up owned by root and need a deliberate ownership change before an ordinary user can read them.

For a malformed or truncated report, leave the original untouched and get a fresh copy from the reporting system. Unpacking the same damaged input over and over will not repair it: the command never modifies the report, so recovery is just discarding the incomplete destination and starting again with a new empty one once you have confirmed the source.

Once you have finished, treat the extracted directory as sensitive temporary data. Remove it only after confirming you no longer need it, and target the exact directory you created: a mistaken recursive removal can take unrelated files with it.