在SWIG封装库中的__cxa_allocate_exception期间的segfault [英] segfault during __cxa_allocate_exception in SWIG wrapped library

问题描述

在为Ruby开发SWIG封装的C ++库时，我们在C ++代码中的异常处理过程中遇到了无法解释的崩溃。

While developing a SWIG wrapped C++ library for Ruby, we came across an unexplained crash during exception handling inside the C++ code.

我不确定情况下重现问题，但它发生在第一次调用 std :: uncaught_exception ，然后一些代码更改后，移动到 __ cxa_allocate_exception 。

I'm not sure of the specific circumstances to recreate the issue, but it happened first during a call to std::uncaught_exception, then after a some code changes, moved to __cxa_allocate_exception during exception construction. Neither GDB nor valgrind provided any insight into the cause of the crash.

我发现几个类似问题的引用，包括：

I've found several references to similar problems, including:

• http://wiki.fifengine.de/Segfault_in_cxa_allocate_exception


• http://forums.fifengine.de/index.php?topic=30.0


• http://code.google.com / p / osgswig / issues / detail？id = 17


• https://bugs.launchpad.net/ubuntu/+source/libavg/+bug/241808

• http://wiki.fifengine.de/Segfault_in_cxa_allocate_exception
• http://forums.fifengine.de/index.php?topic=30.0
• http://code.google.com/p/osgswig/issues/detail?id=17
• https://bugs.launchpad.net/ubuntu/+source/libavg/+bug/241808

重要的主题似乎是多种情况的组合：

The overriding theme seems to be a combination of circumstances:

• AC应用程序已链接到多个C ++库


• 在编译期间使用了多个版本的libstdc ++


• 通常，所使用的第二个版本的C ++来自libGL的二进制实现


• 将库与C ++应用程序（仅使用C应用程序）链接时，不会出现此问题

• A C application is linked to more than one C++ library
• More than one version of libstdc++ was used during compilation
• Generally the second version of C++ used comes from a binary-only implementation of libGL
• The problem does not occur when linking your library with a C++ application, only with a C application

是明确链接你的库与libstdc ++和可能还与libGL，强制链接的顺序。

The "solution" is to explicitly link your library with libstdc++ and possibly also with libGL, forcing the order of linking.

在我的代码中尝试了很多组合后，我发现的唯一解决方案是 LD_PRELOAD =libGL.so libstdc ++。 ruby scriptname 选项。也就是说，没有一个编译时链接解决方案有任何区别。

After trying many combinations with my code, the only solution that I found that works is the LD_PRELOAD="libGL.so libstdc++.so.6" ruby scriptname option. That is, none of the compile-time linking solutions made any difference.

我对这个问题的理解是C ++运行时没有正确初始化。通过强制链接的顺序引导初始化过程和它工作。该问题只发生在C应用程序调用C ++库，因为C应用程序本身不链接到libstdc ++，并且不初始化C ++运行时。因为使用SWIG（或boost :: python）是从C应用程序调用C ++库的常用方法，这就是为什么SWIG经常在研究问题时出现的原因。

My understanding of the issue is that the C++ runtime is not being properly initialized. By forcing the order of linking you bootstrap the initialization process and it works. The problem occurs only with C applications calling C++ libraries because the C application is not itself linking to libstdc++ and is not initializing the C++ runtime. Because using SWIG (or boost::python) is a common way of calling a C++ library from a C application, that is why SWIG often comes up when researching the problem.

有人在那里能够更多地洞察这个问题吗？是否有实际的解决方案或只有解决方案？

Is anyone out there able to give more insight into this problem? Is there an actual solution or do only workarounds exist?

谢谢。

推荐答案

按照Michael Dorgan的建议，我将我的评论复制到答案中：

Following Michael Dorgan's suggestion, I'm copying my comment into an answer:

找到问题的真正原因。希望这将帮助别人遇到这个bug。您可能有某些静态数据未正确初始化。我们做了，解决方案是在我们的代码库的boost-log。 https://sourceforge.net/projects/boost-log/forums/forum/710022/ topic / 3706109 。真正的问题是延迟加载库（加上静态），而不是来自不同库的潜在的多个版本的C ++。有关详情： http://parashift.com/c++-faq-lite/ctors.html# faq-10.13

Found the real cause of the problem. Hopefully this will help someone else encountering this bug. You probably have some static data somewhere that is not being properly initialized. We did, and the solution was in boost-log for our code base. https://sourceforge.net/projects/boost-log/forums/forum/710022/topic/3706109. The real problem is the delay loaded library (plus statics), not the potentially multiple versions of C++ from different libraries. For more info: http://parashift.com/c++-faq-lite/ctors.html#faq-10.13

由于遇到这个问题及其解决方案，我了解到理解静态和静态之间的共享或不共享静态是很重要的动态链接库。在Windows上，这需要显式地导出共享静态的符号（包括单例，意味着跨不同库访问）。每个主要平台之间的行为是微妙的不同。

Since encountering this problem and its solution, I've learned that it's important to understand how statics are shared or not shared between your statically and dynamically linked libraries. On Windows this requires explicitly exporting the symbols for the shared statics (including things like singletons meant to be accessed across different libraries). The behavior is subtly different between each of the major platforms.

这篇关于在SWIG封装库中的__cxa_allocate_exception期间的segfault的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！