9、错误处理与异常安全：插件崩溃隔离、信号处理、setjmp/longjmp 的应用
各位，咱们今天聊一个硬核话题——插件系统的错误处理。说白了，就是怎么让你的主程序不被一个“坏”插件拖下水。
我见过太多项目，插件一崩，整个进程就挂了。用户骂娘，运维抓狂。嗯，这其实是可以避免的。今天我就把我在几个大型插件化项目里踩过的坑、总结的经验，全盘托出。
9.1 插件崩溃隔离：别让一颗老鼠屎坏了一锅粥
插件崩溃隔离，核心思想就一句话：插件是客，主程序是主。客犯错，主担责，但不能陪葬。
怎么隔离？最彻底的办法是进程级隔离——每个插件跑在独立进程里。但代价高，通信复杂。咱们今天重点讲进程内隔离，也就是在同一个进程里，怎么把插件的“破坏力”控制住。
核心原则：
- 插件不能直接操作主程序的内存（除非通过接口）
- 插件不能捕获主程序的信号（除非你允许）
- 插件崩溃时，主程序要能“接住”并恢复
我在一个嵌入式项目里遇到过这种情况：一个第三方图像处理插件，内部有个野指针，一调用就段错误。主程序是监控系统，不能重启。怎么办？
我们用了信号处理 + setjmp/longjmp的组合拳。下面细说。
9.2 信号处理：捕获那些“致命”的信号
插件崩溃，最常见的信号是 SIGSEGV（段错误）和 SIGFPE（浮点异常）。默认情况下，这些信号会让进程直接终止。
我们要做的，就是注册自己的信号处理函数，把“致命”变成“可控”。
#include <stdio.h>
#include <signal.h>
#include <setjmp.h>
static jmp_buf plugin_jmp;
void plugin_signal_handler(int sig) {
// 恢复默认信号处理，防止递归
signal(sig, SIG_DFL);
// 跳回安全点
longjmp(plugin_jmp, sig);
}
void register_plugin_signal_handler() {
signal(SIGSEGV, plugin_signal_handler);
signal(SIGFPE, plugin_signal_handler);
signal(SIGILL, plugin_signal_handler);
signal(SIGABRT, plugin_signal_handler);
}注意：信号处理函数里能做的事非常有限。不能调用 printf、malloc 等非异步信号安全的函数。我一般只做两件事：恢复默认处理，然后 longjmp。
你可能会问：为什么还要恢复默认处理？因为如果 longjmp 失败（比如 jmp_buf 被破坏），至少还能让进程按默认方式退出，而不是陷入死循环。
9.3 setjmp/longjmp：非局部跳转的艺术
setjmp/longjmp 是 C 语言里最接近“异常处理”的机制。它允许你从一个函数直接跳回到另一个函数的某个位置，绕过正常的函数返回流程。
我习惯把 setjmp 放在调用插件函数之前，像这样：
int safe_call_plugin(void (*plugin_func)(void)) {
register_plugin_signal_handler();
int sig = setjmp(plugin_jmp);
if (sig == 0) {
// 正常路径：调用插件
plugin_func();
return 0; // 成功
} else {
// 异常路径：插件崩溃了
fprintf(stderr, "插件崩溃，信号: %d\n", sig);
// 清理资源，恢复状态
return -1; // 失败
}
}这段代码的逻辑很清晰：
setjmp第一次返回 0，表示“设置跳转点成功”。- 如果插件内部崩溃，信号处理函数调用
longjmp，就会跳回到setjmp的位置，但这次返回值是信号编号（非0）。 - 主程序根据返回值判断：哦，插件崩了，我来收拾残局。
避坑指南：我曾经在 longjmp 之后直接调用 free 释放插件分配的内存，结果又崩了一次。为什么？因为 longjmp 跳过了正常的栈展开，一些局部变量的状态是不确定的。我的建议是：在调用插件之前，把所有需要清理的资源记录在全局或静态结构中，跳转后统一清理。
9.4 实战中的陷阱与对策
光有上面的代码还不够。实际项目中，我遇到过几个坑：
| 陷阱 | 后果 | 对策 |
|---|---|---|
| 信号处理函数中调用非安全函数 | 死锁、二次崩溃 | 只做 longjmp 和恢复默认处理 |
longjmp 跳过锁的释放 |
死锁 | 使用 pthread_cleanup_push/pop 或手动管理 |
| 插件修改了全局状态 | 主程序行为异常 | 调用前备份关键状态，崩溃后恢复 |
| 多个插件同时崩溃 | 信号处理混乱 | 每个插件使用独立的 jmp_buf |
嗯，这里重点说一下“锁”的问题。如果插件在持有锁的时候崩溃了，longjmp 跳走，锁永远不会被释放。其他线程再想拿这个锁，就永远卡死了。
我的做法是：在调用插件之前，确保当前线程不持有任何锁。如果必须持有，那就用 trylock 并设置超时，或者干脆把插件调用放在一个独立的线程里。
9.5 知识体系总览
下面这张图，是我对本章知识体系的总结。你看一眼，心里就有谱了。
9.6 一个完整的例子
说了这么多，咱们来一个完整的、可运行的例子。假设你有一个插件函数 plugin_do_work，它可能会崩溃。
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <setjmp.h>
static jmp_buf safe_jmp;
void crash_handler(int sig) {
signal(sig, SIG_DFL);
longjmp(safe_jmp, sig);
}
void setup_safe_call() {
signal(SIGSEGV, crash_handler);
signal(SIGFPE, crash_handler);
signal(SIGILL, crash_handler);
}
int safe_call(void (*func)(void*), void *arg) {
setup_safe_call();
int result = setjmp(safe_jmp);
if (result == 0) {
func(arg);
return 0;
} else {
fprintf(stderr, "[安全调用] 插件崩溃，信号码: %d\n", result);
return -1;
}
}
// 一个可能会崩溃的插件函数
void dangerous_plugin(void *arg) {
int *p = NULL;
*p = 42; // 故意写空指针
}
int main() {
printf("调用插件...\n");
int ret = safe_call(dangerous_plugin, NULL);
if (ret != 0) {
printf("插件调用失败，但主程序继续运行。\n");
}
printf("主程序正常结束。\n");
return 0;
}运行结果：
调用插件...
[安全调用] 插件崩溃，信号码: 11
插件调用失败，但主程序继续运行。
主程序正常结束。看到了吗？插件崩了，但主程序活得好好的。这就是我们想要的效果。
个人经验：我在一个金融交易系统里用过这个模式。插件是第三方提供的策略库，经常有 bug。用了这套机制后，运维人员再也不用半夜爬起来重启服务了。不过要提醒你：这不能替代代码质量。它只是最后一道防线。
9.7 总结
错误处理与异常安全，是插件化架构里最容易忽视、也最容易出问题的一环。我见过太多项目，功能做得花里胡哨，结果一个插件崩溃就全盘崩溃。
记住三个关键词：信号处理、setjmp/longjmp、资源清理。把这三点做到位，你的插件系统才算真正有了“免疫力”。
嗯，今天就聊到这里。代码里的坑，我帮你踩过了，你照着写就行。