看门狗线程终止进程时，触发segfault相比正常退出更优的场景有哪些？

主动触发段错误（SIGSEGV）而非调用exit()终止进程，在工业界生产环境中确实存在很多合理场景，核心差异在于两种终止方式的执行逻辑和故障遗留信息完全不同，常见适用场景如下：

• 留存完整故障现场方便事后排查
  绝大多数服务器、嵌入式环境的默认配置中，进程收到SIGSEGV这类故障信号时会自动生成core dump文件，该文件会保存进程崩溃瞬间的完整调用栈、内存数据、寄存器状态、锁持有情况等所有运行信息。看门狗触发超时意味着进程已经出现了不可恢复的异常（比如业务线程死锁、死循环、阻塞无法喂狗），此时生成的core文件可以直接定位异常根因。而调用exit()属于正常的主动退出流程，默认不会生成core dump，很难回溯超时故障的具体原因。
  你提到的*(char **)0 = "watchdog timeout";属于老代码里常用的野指针触发段错误的写法，优势是不需要依赖任何库函数调用，兼容性极强，甚至在没有raise()实现的精简嵌入式环境中也能生效。
• 规避异常状态下的清理逻辑次生风险
  当看门狗触发超时的时候，进程的内部状态已经是不可信的：可能出现了全局锁被异常持有、动态内存损坏、IO状态异常等问题。此时调用exit()会自动执行用户态注册的atexit回调、全局对象析构函数、IO缓冲区刷新等清理逻辑，很可能出现两种问题：一是清理逻辑本身因为进程状态异常卡住，导致进程无法正常终止；二是错误的清理逻辑会把已经损坏的数据写入磁盘、数据库等持久化存储，造成数据污染。而触发SIGSEGV之后会直接由内核接管终止进程，不会执行任何用户态的清理逻辑，能最快速度终止异常实例，避免故障扩散。
• 适配现有监控体系的异常等级判定
  大部分线上服务的监控体系会天然区分进程“主动正常退出”和“信号异常终止”两种状态，SIGSEGV属于明确的严重故障信号，监控可以直接匹配到该信号后自动触发报警、拉取core文件、实例自愈等标准化故障处理流程。如果使用exit()的话，需要额外约定特殊退出码来标识看门狗超时场景，还要同步修改所有相关的监控、运维脚本配置，适配成本更高，也容易和其他主动退出场景混淆。

你贴出的示例代码中使用raise(SIGSEGV)的写法是更规范的显式触发段错误的实现，可读性远高于野指针写法，语义也更清晰。

内容的提问来源于stack exchange，提问作者qq4