Debugging Crashes | Zed Code Editor Documentation
Description: Learn how to use and customize Zed, the fast, collaborative code editor. Official docs on features, configuration, AI tools, and workflows.

# Debugging Crashes

## Crashes

When an app crashes,

- macOS creates a `.ips` file in `~/Library/Logs/DiagnosticReports`. You can view these using the built in Console app (`cmd-space Console`) under "Crash Reports".
- Linux creates a core dump. See the man pages for pointers to how your system might be configured to manage core dumps.

If you have enabled Zed's telemetry these will be uploaded to us when you restart the app. They end up in a Slack channel (internal only).

These crash reports are generated by the crashing binary, and contain a wealth of information; but they are hard to read for a few reasons:

- They don't contain source files and line numbers
- The symbols are mangled
- Inlined functions are elided

On macOS, to get a better sense of the backtrace of a crash you can download the `.ips` file locally and run:

    ./script/symbolicate ~/path/zed-XXX-XXX.ips

This will download the correct debug symbols from our public digital ocean bucket, and run symbolicate for you.

The output contains the source file and line number, and the demangled symbol information for every inlined frame.

## Panics

When the app panics at the rust level, Zed creates a file in `~/Library/Logs/Zed` or `$XDG_DATA_HOME/zed/logs` with the text of the panic, and a summary of the backtrace. On boot, if you have telemetry enabled, we upload these panics so we can keep track of them.

A panic is also considered a crash, and so for most panics we get both the crash report and the panic.

## Using a Debugger

If you can reproduce the crash consistently, a debugger can be used to inspect the state of the program at the time of the crash, often providing very useful insights into the cause of the crash.

You can read more about setting up and using a debugger with Zed, and specifically for debugging crashes here