当通过OSX上的dlopen打开库时调试崩溃 [英] Debugging a crash when a library is opened via dlopen on OSX
问题描述
线程5崩溃：
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 :: recursi veInitialization（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 ::传入& Ice :: Current const&）+ 572（CDL.cpp：15057）
18 libIce.3.3.1.dylib 0x00000001000c9078 IceInternal :: Incoming :: invoke（IceInternal :: Handle< IceInternal :: ServantManager> const（int），int int，int，int，unsigned char，IceInternal :: Handle<< const&）+ 2004（Incoming.cpp：484）
19 libIce.3.3.1.dylib 0x0000000100091a5d Ice :: ConnectionI :: invokeAll（IceInternal :: BasicStream& ; 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.dyl ib 0x00007fff8167c309 thread_start + 13
（如果需要，我可以发布完整的日志，但超出了正文限制，如果我将其包含在我的帖子中）
在运行可执行文件的终端中，除了运行可执行文件的脚本被捕获一个信号。
我的问题是如何获取有关可能导致此次崩溃的更多信息？如果有人可以，我也很高兴建议可能的解决方案，但从开始我至少想知道如何生成更多的信息，当系统崩溃什么是实际错误。
如果我在最初被dlopen打开的图书馆上运行otool，一切都看起来很好（没有丢失的链接，符号等）。我的主要怀疑是，图书馆正在加载的图书馆的特殊组合与其相关联，导致这种崩溃。可以加载这些其他库，它们使用这些链接库的不同子集。为了记录，这些库包括X11，ZeroC的Ice，Player / Stage和OpenCV（后者2手动编译，使用MacPorts安装依赖关系）。看起来它是引入OpenCV的问题，因为连接到OpenCV之外的所有其他库可以加载没有任何问题。这些是我的怀疑，但我目前缺乏进一步调查的专门知识。
谢谢！尼克
更新：感谢Kaelin的答案（DYLD_PRINT_ *选项，我以前没有意识到）我能够至少确认没有什么完全明显的发生。使用调试信息，我可以将问题缩小到导致崩溃的特定库。原来，这个库（libdc1394通过OpenCV中的libhighgui连接到我的应用程序）与CoreServices没有正确链接，这导致崩溃。由于某些原因，错误被其他东西隐藏，导致最终的崩溃。有关libdc1394问题的信息，请查看此处。不幸的是，我无法做出一个干净的修复，我可以在这里报告，所以只是设法得到一个运行的应用程序的版本没有链接到躲避库（通过关闭libdc1394在OpenCV编译）。
dyld正在共享库中运行初始化器（在C ++中考虑静态初始化器），其中之一是引起CoreFoundation框架__CFInitialize函数要运行。 [这可能是第一件碰巧的CoreFoundation吗？]无论什么原因，__CFInitialize都不开心。这可能是某种缺失的依赖。或者可能是堆被破坏了。或者它可能是CoreFoundation框架中某种潜在的错误。
我建议修改前两种可能性：a）运行所有DYLD_PRINT_ *环境变量集[见 man dyld ]和b）在MallocDebug下运行。如果这两个人都没有发光，那么你可能已经为CoreFoundation的人们写下了一个雷达。
I have a problem with a C++ application I've developed which uses dlopen to load user-developed libraries. The application has been used by a variety of people on a variety of linux distros and versions of OSX over the last couple of years and so I'm assuming my usage of dlopen is OK and so is the code that depends on it (yeah, this is hubris, so I'll report back when it fails). The problem I have now is that a user has developed a library which does not load on my system (OSX 10.6.4). When the system tries to load it there is a freeze then a crash. The thread that crashes looks like this in the crash report:
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
(I can post the full log if needed, but it exceeds the body text limit if I include it in my post)
In the terminal where I'm running the executable the crash produces no output except for the notification that script running the executable has trapped a signal.
My question is how do I get more information on what might be causing this crash? I'm also happy if someone can suggest possible solutions, but to start with I'd at least like to know how to generate more information when the system crashes about what is actually wrong.
If I run otool on the library which is being initially being opened by dlopen everything looks fine (no missing links, symbols etc). My main suspicion is that it is the particular combination of libraries which the library being loaded is linked against which is causing this crash somehow. These other libraries can be loaded which use different subsets of these linked-against libraries. For the record the libraries include X11, ZeroC's Ice, Player/Stage and OpenCV (with the latter 2 compiled manually with dependencies installed using MacPorts). It seems it's the inclusion of OpenCV which causes the problem, as other libraries which link to all of these except OpenCV can be loaded with no problems. These are my suspicions, but I currently lack the know-how to investigate further.
Thanks! Nick
UPDATE: Thanks to Kaelin's answer (the DYLD_PRINT_* options which I wasn't previously aware of) I was able to at least confirm that nothing completely obvious was happening. Using the debug information I was able to narrow the problem down to one particular library which was causing the crash. It turned out that this library (libdc1394 linked into my app via libhighgui in OpenCV) wasn't correctly linked against CoreServices and this was causing the crash. For some reason the error was then hidden by other things, causing the ultimate crash. For info on the libdc1394 problem, look here. Unfortunately I couldn't make a clean fix that I can report here, so just managed to get a version of the app running that didn't link to the dodgy library (by turning off libdc1394 in OpenCV compilation).
dyld is running the initializers in the shared library (think static initializers in C++), and one of them is causing CoreFoundation framework's __CFInitialize function to be run. [Is it possible this is the first thing touching CoreFoundation?] And for whatever reason, __CFInitialize is not happy. This could be some kind of missing dependency. Or it could be the heap is corrupted. Or it could be a latent bug of some kind in CoreFoundation framework.
I would suggest trimming the first two possibilities by a) running with all of the DYLD_PRINT_* environment variables set [see man dyld] and b) running under MallocDebug. If neither of those shed any light, you're probably left with writing a radar for the CoreFoundation folks to look at.
这篇关于当通过OSX上的dlopen打开库时调试崩溃的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
