У меня проблема с разработанным мною приложением 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
(я могу опубликовать полный журнал, если это необходимо, но он превышает лимит основного текста, если я включу его в свой пост)
В терминале, где я запускаю исполняемый файл, сбой не выводит ничего, кроме уведомления о том, что скрипт, выполняющий исполняемый файл, перехватил сигнал.
У меня вопрос как мне получить больше информации о том, что может быть причиной этого сбоя? Я также рад, если кто-то может предложить возможные решения, но для начала мне хотелось бы хотя бы узнать как генерировать больше информации при сбоях системы о том, что на самом деле не так.
Если я запускаю otool в библиотеке, которая первоначально открывается dlopen, все выглядит нормально (без отсутствующих ссылок, символов и т. Д.). Мое основное подозрение заключается в том, что именно с определенной комбинацией библиотек, с которой связана загружаемая библиотека, что-то вызывает этот сбой. Эти другие библиотеки могут быть загружены, которые используют различные подмножества этих связанных библиотек. Для записи библиотеки включают X11, Ice ZeroC, Player / Stage и OpenCV (последние 2 скомпилированы вручную с зависимостями, установленными с помощью MacPorts). Кажется, проблема связана с включением OpenCV, так как другие библиотеки, которые ссылаются на все это, кроме OpenCV, могут быть загружены без проблем. Это мои подозрения, но в настоящее время мне не хватает ноу-хау для дальнейшего расследования.
Спасибо! Ник
ОБНОВЛЕНИЕ: Благодаря ответу Каэлина (варианты DYLD_PRINT_ *, о которых я раньше не знал), я смог, по крайней мере, подтвердить, что ничего совершенно очевидного не происходит. Используя отладочную информацию, я смог сузить проблему до одной конкретной библиотеки, которая вызывала сбой. Оказалось, что эта библиотека (libdc1394, связанная с моим приложением через libhighgui в OpenCV) не была правильно связана с CoreServices, и это вызывало сбой. По какой-то причине ошибка была скрыта другими вещами, что привело к окончательному сбою. Для получения информации о проблеме libdc1394 посмотрите здесь . К сожалению, я не смог сделать чистое исправление, о котором я мог бы сообщить здесь, поэтому просто смог получить версию работающего приложения, которая не ссылалась на изворотливую библиотеку (отключив libdc1394 в компиляции OpenCV).