Отладка сбоя при открытии библиотеки через dlopen на 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

(я могу опубликовать полный журнал, если нужно, но он превышает лимит основного текста, если я включу его в свое сообщение)

В терминале, где я запускаю исполняемый файл, крах не дает никакого вывода, кроме уведомления о том, что скрипт, запускающий исполняемый файл, поймал сигнал.

Мой вопрос в том, как мне получить больше информации о том, что может быть причиной этого сбоя? Я также буду рад, если кто-нибудь предложит возможные решения, но для начала я хотел бы знать, как генерировать больше информации о том, что на самом деле не так.

Если я запускаю otool на библиотеке, которая изначально открывается dlopen, все выглядит нормально (никаких недостающих ссылок, символов и т.д.). Мое основное подозрение заключается в том, что именно определенная комбинация библиотек, с которыми связана загружаемая библиотека, каким-то образом вызывает этот сбой. При этом могут быть загружены другие библиотеки, которые используют различные подмножества этих связанных библиотек. Для справки, эти библиотеки включают X11, ZeroC's Ice, Player/Stage и OpenCV (причем последние две скомпилированы вручную с зависимостями, установленными с помощью MacPorts). Похоже, что именно включение OpenCV вызывает проблему, так как другие библиотеки, которые ссылаются на все эти библиотеки, кроме OpenCV, могут быть загружены без проблем. Таковы мои подозрения, но в настоящее время мне не хватает ноу-хау для дальнейшего расследования.

Спасибо! Nick

UPDATE: Благодаря ответу Kaelin (опции DYLD_PRINT_*, о которой я раньше не знал) я смог по крайней мере подтвердить, что ничего совершенно очевидного не происходит. Используя отладочную информацию, я смог свести проблему к одной конкретной библиотеке, которая вызывала сбой. Оказалось, что эта библиотека (libdc1394, связанная в моем приложении через libhighgui в OpenCV) была неправильно связана с CoreServices, что и вызывало сбой. По какой-то причине ошибка была скрыта другими вещами, что привело к окончательному сбою. Информацию о проблеме libdc1394 смотрите здесь. К сожалению, я не смог сделать чистое исправление, о котором можно было бы сообщить здесь, поэтому только что удалось запустить версию приложения, которая не ссылается на сомнительную библиотеку (отключив libdc1394 в компиляции OpenCV).

7
задан Nick Hawes 26 August 2010 в 06:31
поделиться

1 ответ

dyld запускает инициализаторы в разделяемой библиотеке (подумайте о статических инициализаторах в C ++), и один из них вызывает выполнение функции __CFInitialize CoreFoundation framework. [Возможно ли, что это первое, что касается CoreFoundation?] И по какой-то причине __CFInitialize недоволен. Это может быть какая-то недостающая зависимость. Или это может быть куча повреждена. Или это может быть какая-то скрытая ошибка в структуре CoreFoundation.

Я бы посоветовал урезать первые две возможности: а) работать со всеми установленными переменными среды DYLD_PRINT_ * [см. man dyld ] и б) работать под MallocDebug. Если ни один из них не пролил свет, вам, вероятно, осталось написать радар, на который люди из CoreFoundation могли бы взглянуть.

3
ответ дан 7 December 2019 в 01:14
поделиться
Другие вопросы по тегам:

Похожие вопросы: