Linux/Android

在Linux上，这是通过处理以下信号来完成的。

Linux信号处理的一个重要细节是，这个crate通过挂钩 signals 来处理 pthread_create，以便在每个线程上始终安装一个备用信号栈。 std::thread::Thread 已经这样做，但是通过挂钩 pthread_create 可以确保从例如C/C++代码创建的线程也能这样做。备用栈对于可靠地处理由 SIGSEGV 引起的 堆栈溢出 是必要的，因为否则信号会在引发信号的同一堆栈上处理。

SIGABRT

发送给进程的信号，告诉它中止，即终止。该信号通常由进程本身在调用 std::process::abort 或 libc::abort 时发起，但它可以像任何其他信号一样从进程外部发送。

SIGBUS

当进程引发 总线错误 时发送给进程的信号。

SIGFPE

当进程执行错误算术运算时发送给进程的信号。尽管它代表 floating point exception，但此信号还涵盖了整数运算。

SIGILL

当进程尝试执行非法、格式不正确、未知或受保护的指令时发送给进程的信号。

SIGSEGV

当进程进行无效的虚拟内存引用时，会发送信号到一个进程，例如，一个段错误。这包括臭名昭著的 null 指针访问、越界访问、使用后释放、栈溢出等。

SIGTRAP

当触发陷阱时，会发送信号到一个进程，例如，一个断点或调试断言。

Windows

在Windows中，我们捕获异常，这些异常涵盖了广泛的崩溃原因，以及无效参数和纯调用

MacOS

在Macos上，我们使用异常端口。异常端口是异常过滤的第一层，从线程级别到进程（任务）级别，最后到主机级别。

如果没有注册用户端口，Macos的默认实现是将Mach异常转换为等效的Unix信号，并在执行异常/信号的默认操作（即进程终止）之前将其发送给任何注册的信号处理器。这意味着如果您在Macos上与信号处理结合使用此crate，您将不会得到预期的结果，因为此crate使用的异常端口将优先于信号处理器。请参阅此问题以获取具体示例。

注意，上述情况有一个例外，即SIGABRT由信号处理器处理，因为没有等效的Mach异常。

EXC_BAD_ACCESS

涵盖了与SIGSEGV和SIGBUS类似的崩溃。

EXC_BAD_INSTRUCTION

涵盖了与SIGILL类似的崩溃。

EXC_ARITHMETIC

涵盖了与SIGFPE类似的崩溃。

EXC_BREAKPOINT

涵盖了与SIGTRAP类似的崩溃。

贡献

我们欢迎社区为此项目做出贡献。

请阅读我们的贡献指南以了解更多关于如何开始的信息。在您做出任何贡献之前，也请阅读我们的贡献条款。

任何有意提交以包含在Embark Studios项目中的贡献，都应遵守Rust标准许可模型（MIT OR Apache 2.0），因此将双重许可，如下所述，不附加任何额外条款或条件

许可

此贡献在以下两者下双重许可

• Apache License, Version 2.0, (LICENSE-APACHE 或 http://www.apache.org/licenses/LICENSE-2.0)
• MIT许可 (LICENSE-MIT 或 http://opensource.org/licenses/MIT)

任选其一。

为了明确，“您的”指的是Embark或任何其他贡献许可方/用户。