created_at2019-09-15 00:52:51.426613
updated_at2023-01-02 06:43:35.414737
descriptionForce coredump creation on panics.
Daniel Müller (d-e-s-o)



pipeline Docs rustc


coredump is a crate to make a Rust program create a core dump when it encounters a panic.


By default, when a Rust program panics it will print a backtrace and terminate the program. There are a few situations when this behavior is not sufficient or desired, including when:

  • you want to make sure that you are able to root cause problems based on bug reports and a backtrace alone may not be enough
  • you cannot get the backtrace of a panic, for example, because it is printed to the terminal's alternate screen or otherwise not available

coredump caters to those and more cases. It should combine with and may be a nice addition to other crates involved in the panic path, such as human-panic.


The crate works by registering a custom panic handler that will run after the previously installed (or default) one. Registration of this custom handler is as simple as invoking:


early during program initialization (ideally before any panic may happen).

After a panic has happened, the core file can be investigated using gdb(1), like so:

$ rust-gdb <paniced-binary> <core-file>

By default a core file as created by this crate will reside in the system's temp directory, but this behavior may be overwritten by system configuration.


By design, this crate is concerned only with regular (language level) panics. Segmentation violations or other problems are not covered by its approach. The application using this crate also will have to be compiled with proper unwinding support and not just abort execution (unwinding is the case by default but could be overwritten by adding panic = 'abort' to the profile being compiled against).

Also note that while core dumping support is present on many systems, many factors play into the ability of a system to create an application core dump. A lot of these factors are out of this crate's control, both in the sense that they cannot be changed but also that they may potentially not even be checkable at runtime. The full list of requirements the system must meet is detailed in core(5).

Commit count: 14

cargo fmt