启用 faulthandler 可定位 Segmentation fault 崩溃点，它会打印崩溃前 C 调用栈，指向 ctypes 或模块加载环节；需严格校验 ctypes 类型、内存生命周期及共享库兼容性。
用 faulthandler 定位崩溃发生点
Segmentation fault 不经过 Python 异常机制，try/except 捕获不到，也看不到 traceback。最直接有效的定位方式是启用 faulthandler：
- 命令行启动时加参数：
python -X faulthandler your_script.py - 或在脚本最开头（import 之后、任何其他逻辑之前）插入：
import faulthandler; faulthandler.enable()
它会打印出崩溃前最后一段 C 调用栈，比如指向 ctypes/__init__.py 第 374 行，或某个第三方包的 load_library 调用——这说明问题大概率出在模块加载或首次调用环节，而非业务逻辑中间。
ctypes 调用中常见类型不匹配陷阱
Python 的 ctypes 默认把 C 函数返回值当 c_int 处理，但很多 SDK（如安防设备、硬件驱动）返回的是 LLONG 或指针。类型错配会导致高位截断，后续传入该值作为句柄时被当作非法地址访问，直接触发段错误。
- 必须显式设置
restype：例如SDK._dll.CLIENT_Login.restype = c_longlong - 输入参数也要核对：字符串要用
c_buffer或c_char_p，结构体传引用用byref()，不能直接传实例 - 特别注意指针参数：如果 C 函数要写入内容到你传入的缓冲区，务必确保缓冲区已分配且足够大，否则越界写入就是段错误温床
导入顺序与模块冲突引发的静默崩溃
某些 C 扩展（如 torch_sparse、cv2、自定义 SDK）内部依赖特定版本的 OpenMP、CUDA 运行时或系统库。多个扩展同时加载时，若共享库版本不兼容或初始化顺序冲突，可能在 import 阶段就崩掉，表现为“一导入就 Segmentation fault (core dumped)”。
立即学习“Python免费学习笔记（深入）”；
- 先最小化复现：新建空脚本，只 import 出问题的模块，看是否立即崩溃
- 逐个注释其他 import，尤其是
torch、numpy、cv2这类重量级扩展，观察崩溃是否消失 - 避免混用不同构建方式的包：比如 conda 安装的
opencv和 pip 安装的torch可能链接不同 glibc 版本，换统一渠道重装常能解决
回调函数与多线程场景下的内存生命周期风险
当 Python 向 C 传递回调函数（如事件通知、数据接收），C 层会在任意时刻调用它。如果回调里用了局部变量、临时 bytes 对象或未持久化的 numpy 数组，而 C 层又试图长期持有其指针，Python GC 回收后，C 再访问就是野指针。
- 所有传给 C 的缓冲区（如
c_char_p、ndarray.data）必须在回调整个生命周期内有效——通常得提升为全局变量或类成员 - 避免在回调中直接操作
ctypes创建的临时对象；改用create_string_buffer分配固定内存，并确保 C 不会越界读写 - 多线程下尤其危险：
threading+ctypes+ 共享结构体，若没加锁或没用Lock保护临界区，底层内存可能被并发破坏
真正棘手的不是崩溃本身，而是它发生在 Python 看不见的地方。一旦 faulthandler 指向某个 ctypes 调用或 import 行，就得立刻怀疑类型、内存、链接这三个维度——它们不报错，只沉默地让进程消失。
