在Go代码中处理C/C++库的异常

Golang小白一枚，正在不断学习积累知识，现将学习到的知识记录一下，也是将我的所得分享给大家！而今天这篇文章《在Go代码中处理C/C++库的异常》带大家来了解一下##content_title##，希望对大家的知识积累有所帮助，从而弥补自己的不足，助力实战开发！

我在go代码中使用cgo访问c/c++库，发现了一些如下异常日志：

fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x90 pc=0x7ff0fbdc23ff]

....

STACK ...

现在我可以确认异常来自c/c++库，但是即使我编写了恢复代码，这个异常也会使我的go程序崩溃。（ps：似乎我无法恢复致命错误）。 p>

我的场景：

1. go程序会接收来自mq的消息
2. go程序调用c库来处理消息
3. 将消息处理标记为完成。

在此过程中，go程序可能会收到错误的消息（例如：无效的消息格式）。错误的消息可能会使c库崩溃，并且在go程序中找不到它，当c库崩溃时我无能为力，即使我想在go程序重新启动时跳过错误消息。

有没有办法捕获c/c++库中的异常？

或者一般来说，cgo 中错误处理的最佳实践是什么？

解决方案

我想强调 @Not_a_Golfer 所说的：当操作系统遇到它试图访问它必须从未尝试过访问的内存时，进程会发送 SIGSEGV 信号。

问题在于，此类错误的原因可能确实是“无害的”（见下文），也可能不是。

• 无害可能就像尝试在对进程无效的地址读取某些内存。最常见的情况是尝试取消引用所谓的 NULL 指针。

  在这种情况下，进程可能不会覆盖一定范围的内存，并且如果幸运的话，中止操作可能会让进程突然消失。 .

  不过，这不是独角兽和彩虹：如果进程在操作开始之前分配了一些内存，那么很可能会导致内存泄漏。

• 严重的情况是由于写入不适合该进程的内存区域而导致的。
  它们的问题是，当进程到达无效的内存区域时，它可能已经覆盖了自己的实时数据结构，这是不希望的。

  在这种情况下，所有的赌注都完全失败了。

无论导致无效内存访问的特定问题属于哪一类，请注意，它表明程序至少包含一个逻辑错误，并且执行了执行该错误的代码路径。这意味着该过程现在处于某种未定义的状态，因为此类错误很容易“传播”：当程序的其他不相关部分可能开始行为不当时，它们可能会导致级联效应，因为它们的逻辑所基于的不变量被无意中更改了。 p>

在您的情况下，代码似乎访问地址 0x90 处的内存，这看起来像是涉及 NULL 指针的经典指针算术（只是猜测，但仍然如此）。

在这种情况下我会做的是：

• 将此库封装在单独的进程中，并通过任何类型的 IPC 与其进行通信。
• 一旦死亡，生成另一个副本来代替它并重试。

无论如何，如果可能的话，请尝试解决根本原因。

1 在操作系统捕获对无效内存区域的访问后正确恢复执行本身就是一项艰巨的任务 - 例如，请参阅 this。
基本上，你必须实现一个自定义信号处理程序，它将以这样的方式进行设置：操作系统将重新启动执行进程的代码，而不是从实际访问该内存块并爆炸的 CPU 指令，而是使用已知的良好位置（据说应该是库入口点函数出口附近的某个地方，该函数在其调用路径的某个位置执行了错误代码。
并且您需要正确恢复堆栈指针，并且可能是其他东西。

真的，这不是你经常做的事情。
对库映像进行二进制修补以防止执行错误的代码路径或将它们转移到添加到映像中的固定对应路径甚至可能会消耗更少的资源，就像通过类似于 those done for TTD 的二进制修补完成的错误修复一样。

今天关于《在Go代码中处理C/C++库的异常》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！