在__cxa_allocate_exception中的SWF包装库中的segfault [英] segfault during __cxa_allocate_exception in SWIG wrapped library

问题描述

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

我不知道具体的重新创建问题的情况，但是在调用 std :: uncaught_exception 之前首先发生，然后在一些代码更改后，移动到 __ cxa_allocate_exception 在异常构造期间。 GDB和valgrind都没有提供对崩溃原因的洞察。

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

• 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

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

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


• 超过o在编译期间使用了新的libstdc ++版本。


• 一般来说，使用的第二个C ++版本来自libGL的二进制实现


• 问题不在于当您的库与C ++应用程序链接时，只能使用C应用程序

解决方案是将库与libstdc ++也可能与libGL，强制链接的顺序。

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

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

谢谢。

解决方案

按照迈克尔·多根的建议，我将我的评论复制到一个答案中：

找到问题的真正原因。希望这将有助于别人遇到这个错误。你可能在一些没有被正确初始化的地方有一些静态数据。我们做了，解决方案是在我们的代码库中进行升级。 https://sourceforge.net/projects/boost-log/forums /论坛/ 710022 /主题/ 3706109 。真正的问题是延迟加载库（加上静态），而不是来自不同库的可能多个C ++版本。欲了解更多信息： http://parashift.com/c++-faq-lite /ctors.html#faq-10.13

自从遇到此问题及其解决方案之后，我了解到了解如何共享静态是非常重要的在静态和动态链接的库之间共享。在Windows上，这需要显式地导出共享静态的符号（包括意图在不同的库之间访问的单例）。每个主要平台之间的行为是微不足道的。

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

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

The overriding theme seems to be a combination of circumstances:

• 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

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

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.

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?

Thanks.

解决方案

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

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

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.

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