繁体   English   中英

在OSX上通过dlopen打开库时调试崩溃

[英]Debugging a crash when a library is opened via dlopen on OSX

我在开发的C ++应用程序中遇到问题,该应用程序使用dlopen加载用户开发的库。 在过去的几年里,应用程序已被各种各样的人使用在各种Linux发行版和OSX版本上,因此我假设我使用dlopen是可以的,依赖于它的代码也是如此(是的,这是狂妄自大,所以当它失败时我会报告回来。 我现在遇到的问题是用户开发了一个不在我的系统上加载的库(OSX 10.6.4)。 当系统尝试加载它时会发生冻结然后崩溃。 在崩溃报告中崩溃的线程如下所示:

Thread 5 Crashed:
0   com.apple.CoreFoundation        0x00007fff80fa6110 __CFInitialize + 1808
1   dyld                            0x00007fff5fc0d5ce ImageLoaderMachO::doImageInit(ImageLoader::LinkContext const&) + 138
2   dyld                            0x00007fff5fc0d607 ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 27
3   dyld                            0x00007fff5fc0bcec ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int) + 236
4   dyld                            0x00007fff5fc0bc9d ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int) + 157
5   dyld                            0x00007fff5fc0bc9d ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int) + 157
6   dyld                            0x00007fff5fc0bc9d ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int) + 157
7   dyld                            0x00007fff5fc0bc9d ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int) + 157
8   dyld                            0x00007fff5fc0bc9d ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int) + 157
9   dyld                            0x00007fff5fc0bda6 ImageLoader::runInitializers(ImageLoader::LinkContext const&) + 58
10  dyld                            0x00007fff5fc08fbb dlopen + 573
11  libSystem.B.dylib               0x00007fff816492c0 dlopen + 61
12  cast-server-c++                 0x0000000100007819 cast::loadLibrary(std::string const&) + 96 (ComponentCreator.cpp:43)
13  cast-server-c++                 0x00000001000079c7 cast::createComponentCreator(std::string const&) + 24 (ComponentCreator.cpp:87)
14  cast-server-c++                 0x00000001000089c5 cast::CASTComponentFactory::createBase(std::string const&, std::string const&, Ice::Current const&) + 197 (CASTComponentFactory.cpp:27)
15  cast-server-c++                 0x00000001000090e9 cast::CASTComponentFactory::newManagedComponent(std::string const&, std::string const&, bool, Ice::Current const&) + 73 (CASTComponentFactory.cpp:62)
16  libCDL.dylib                    0x00000001009ceb6c cast::interfaces::ComponentFactory::___newManagedComponent(IceInternal::Incoming&, Ice::Current const&) + 218 (CDL.cpp:14904)
17  libCDL.dylib                    0x00000001009cf1d0 cast::interfaces::ComponentFactory::__dispatch(IceInternal::Incoming&, Ice::Current const&) + 572 (CDL.cpp:15057)
18  libIce.3.3.1.dylib              0x00000001000c9078 IceInternal::Incoming::invoke(IceInternal::Handle<IceInternal::ServantManager> const&) + 2004 (Incoming.cpp:484)
19  libIce.3.3.1.dylib              0x0000000100091a5d Ice::ConnectionI::invokeAll(IceInternal::BasicStream&, int, int, unsigned char, IceInternal::Handle<IceInternal::ServantManager> const&, IceInternal::Handle<Ice::ObjectAdapter> const&) + 367 (ConnectionI.cpp:2436)
20  libIce.3.3.1.dylib              0x000000010009bb40 Ice::ConnectionI::message(IceInternal::BasicStream&, IceInternal::Handle<IceInternal::ThreadPool> const&) + 416 (ConnectionI.cpp:1105)
21  libIce.3.3.1.dylib              0x00000001001a9bbc IceInternal::ThreadPool::run() + 3470 (ThreadPool.cpp:523)
22  libIce.3.3.1.dylib              0x00000001001aa4ec IceInternal::ThreadPool::EventHandlerThread::run() + 152 (ThreadPool.cpp:782)
23  libIceUtil.3.3.1.dylib          0x00000001006eb1e9 startHook + 128 (Thread.cpp:375)
24  libSystem.B.dylib               0x00007fff8167c456 _pthread_start + 331
25  libSystem.B.dylib               0x00007fff8167c309 thread_start + 13

(如果需要,我可以发布完整的日志,但是如果我将其包含在我的帖子中,它会超出正文限制)

在我正在运行可执行文件的终端中,除了运行可执行文件的脚本捕获了信号的通知之外,崩溃不会产生任何输出。

我的问题是如何获得有关可能导致此次崩溃的更多信息? 如果有人可以提出可能的解决方案,我也很高兴,但首先我至少想知道当系统崩溃时会产生更多信息。

如果我在最初由dlopen打开的库上运行otool,一切看起来都很好(没有丢失的链接,符号等)。 我的主要怀疑是,正在加载的库被链接到的库的特定组合以某种方式导致此崩溃。 可以加载这些其他库,这些库使用这些链接库的不同子集。 为了记录,库包括X11,ZeroC的Ice,Player / Stage和OpenCV(后者2手动编译,使用MacPorts安装依赖项)。 似乎包含OpenCV导致问题,因为除了OpenCV之外链接到所有这些的其他库可以加载没有问题。 这些是我的怀疑,但我目前缺乏进一步调查的专业知识。

谢谢! 缺口

更新:感谢Kaelin的回答(我以前没有意识到的DYLD_PRINT_ *选项),我至少可以确认没有发生任何完全明显的事情。 使用调试信息,我能够将问题缩小到一个导致崩溃的特定库。 事实证明,这个库(libdc1394通过OpenCV中的libhighgui链接到我的应用程序)没有正确链接到CoreServices,这导致了崩溃。 由于某种原因,错误被其他东西隐藏,导致最终崩溃。 有关libdc1394问题的信息,请查看此处 不幸的是我无法做出我可以在这里报告的干净修复,所以只是设法得到一个版本的应用程序运行没有链接到狡猾的库(通过在OpenCV编译中关闭libdc1394)。

经过一些进一步的问题和一些进一步的谷歌搜索,我最终找到了我的问题的真正原因。

如果首先没有初始化CoreFoundation,则无法在(子)线程中调用dlopen与CoreFoundation链接的库。 调用CFInitialize,显然检查线程是否是主线程,如果不是,则使用SIGTRAP崩溃。

http://openradar.appspot.com/7209349

dyld正在共享库中运行初始化器(想想C ++中的静态初始化器),其中一个正在运行CoreFoundation框架的__CFInitialize函数。 [这可能是第一件触及CoreFoundation的东西吗?]无论出于何种原因,__ CFInitialize并不开心。 这可能是某种缺失的依赖。 或者它可能是堆已损坏。 或者它可能是CoreFoundation框架中的某种潜在错误。

我建议通过a)运行所有DYLD_PRINT_ *环境变量集[参见man dyld ]和b)在MallocDebug下运行来修改前两种可能性。 如果这些都没有任何光线,你可能会留下为CoreFoundation人员写一个雷达来观察。

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM