| Crates.io | crash-handler |
| lib.rs | crash-handler |
| version | 0.6.3 |
| created_at | 2022-04-29 14:20:25.53967+00 |
| updated_at | 2025-05-13 17:20:14.827777+00 |
| description | Allows running of user code during crash events |
| homepage | https://github.com/EmbarkStudios/crash-handling/tree/main/crash-handler |
| repository | https://github.com/EmbarkStudios/crash-handling |
| max_upload_size | |
| id | 577385 |
| size | 146,929 |
On Linux this is done by handling signals, namely the following.
One important detail of the Linux signal handling is that this crate hooks pthread_create so that an alternate signal stack is always installed on every thread. [std::thread::Thread] already does this, however hooking pthread_create allows us to ensure this occurs for threads created from eg. C/C++ code as well. An alternate stack is necessary to reliably handle a SIGSEGV caused by a stack overflow, as signals are otherwise handled on the same stack that raised the signal.
SIGABRTSignal sent to a process to tell it to abort, i.e. to terminate. The signal is usually initiated by the process itself when it calls std::process::abort or libc::abort, but it can be sent to the process from outside itself like any other signal.
SIGBUSSignal sent to a process when it causes a bus error.
SIGFPESignal sent to a process when it executes an erroneous arithmetic operation. Though it stands for floating point exception this signal covers integer operations as well.
SIGILLSignal sent to a process when it attempts to execute an illegal, malformed, unknown, or privileged, instruction.
SIGSEGVSignal sent to a process when it makes an invalid virtual memory reference, a segmentation fault. This covers infamous null pointer access, out of bounds access, use after free, stack overflows, etc.
SIGTRAPSignal sent to a process when a trap is raised, eg. a breakpoint or debug assertion.
On Windows we catch exceptions, which cover a wide range of crash reasons, as well as invalid parameters and purecall
MacOSOn Macos we use exception ports. Exception ports are the first layer that exceptions are filtered, from a thread level, to a process (task) level, and finally to a host level.
If no user ports have been registered, the default Macos implementation is to convert the Mach exception into an equivalent Unix signal and deliver it to any registered signal handlers before performing the default action for the exception/signal (ie process termination). This means that if you use this crate in conjunction with signal handling on MacOS, you will not get the results you expect as the exception port used by this crate will take precedence over the signal handler. See this issue for a concrete example.
Note that there is one exception to the above, which is that SIGABRT is handled by a signal handler, as there is no equivalent Mach exception for it.
EXC_BAD_ACCESSCovers similar crashes as SIGSEGV and SIGBUS
EXC_BAD_INSTRUCTIONCovers similar crashes as SIGILL
EXC_ARITHMETICCovers similar crashes as SIGFPE
EXC_BREAKPOINTCovers similar crashes as SIGTRAP
We welcome community contributions to this project.
Please read our Contributor Guide for more information on how to get started. Please also read our Contributor Terms before you make any contributions.
Any contribution intentionally submitted for inclusion in an Embark Studios project, shall comply with the Rust standard licensing model (MIT OR Apache 2.0) and therefore be dual licensed as described below, without any additional terms or conditions:
This contribution is dual licensed under EITHER OF
at your option.
For clarity, "your" refers to Embark or any other licensee/user of the contribution.