Debuggen eines Absturzes, wenn eine Bibliothek über dlopen auf OSX geöffnet wird

Question

Ich habe ein Problem mit einer C++ - Anwendung, die ich entwickelt habe, die dlopen benutzt, um vom Benutzer entwickelte Bibliotheken zu laden. Die Anwendung wurde in den letzten Jahren von einer Vielzahl von Leuten auf verschiedenen Linux-Distributionen und -Versionen von OSX verwendet. Daher nehme ich an, dass meine Verwendung von dlopen in Ordnung ist und auch der Code, der davon abhängt (ja, Das ist Hybris, also melde ich mich, wenn es schief geht. Das Problem, das ich jetzt habe, ist, dass ein Benutzer eine Bibliothek entwickelt hat, die nicht auf meinem System geladen wird (OSX 10.6.4). Wenn das System versucht, es zu laden, gibt es ein Einfrieren und dann einen Absturz. Der Faden, der im Crash-Bericht wie folgt aussieht stürzt:

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 

(ich kann das volle Protokoll schreiben, wenn nötig, aber es übersteigt den Textkörper Grenze, wenn ich es in meinem Beitrag enthalten)

In der Terminal, wo ich die ausführbare Datei ausführe der Crash produziert keine Ausgabe mit Ausnahme der Benachrichtigung, dass Skript, das die ausführbare Datei ausführt, ein Signal abgefangen hat.

Meine Frage ist Wie bekomme ich mehr Informationen darüber, was diesen Absturz verursachen könnte? Ich freue mich auch, wenn jemand mögliche Lösungen vorschlagen kann, aber am Anfang möchte ich zumindest wissen, wie man mehr Informationen generiert, wenn das System abstürzt, was eigentlich falsch ist.

Wenn ich otool auf der Bibliothek laufen lasse, die zuerst von dlopen geöffnet wird, sieht alles gut aus (keine fehlenden Verbindungen, Symbole usw.). Mein Hauptverdacht ist, dass es die besondere Kombination von Bibliotheken ist, mit der die geladene Bibliothek verbunden ist, die diesen Absturz irgendwie verursacht. Diese anderen Bibliotheken können geladen werden, die verschiedene Teilmengen dieser verknüpften Bibliotheken verwenden. Für die Aufzeichnung enthalten die Bibliotheken X11, ZeroCs Ice, Player/Stage und OpenCV (wobei die letzteren 2 manuell mit Abhängigkeiten kompiliert werden, die mit MacPorts installiert wurden). Es scheint, dass es die Einbeziehung von OpenCV ist, die das Problem verursacht, da andere Bibliotheken, die auf alle außer OpenCV verlinken, problemlos geladen werden können. Das sind meine Vermutungen, aber mir fehlt derzeit das Know-how, um weiter zu forschen.

Danke! Nick

UPDATE: Dank Kaelins Antwort (die DYLD_PRINT_ * -Optionen, die ich vorher nicht kannte) konnte ich zumindest bestätigen, dass nichts völlig Offensichtliches geschah. Mit den Debug-Informationen konnte ich das Problem auf eine bestimmte Bibliothek eingrenzen, die den Absturz verursacht hat. Es stellte sich heraus, dass diese Bibliothek (libdc1394 in meiner App über libhighgui in OpenCV verlinkt) nicht korrekt mit CoreServices verknüpft war und dies den Absturz verursachte. Aus irgendeinem Grund wurde der Fehler dann von anderen Dingen verdeckt und verursachte den ultimativen Absturz. Für Informationen über das libdc1394 Problem, schauen Sie here. Leider konnte ich keine saubere Reparatur machen, die ich hier melden kann, also habe ich gerade eine Version der App laufen lassen, die nicht mit der fragwürdigen Bibliothek verlinkt ist (indem ich libdc1394 in der OpenCV-Kompilierung abgeschaltet habe).

Answer 1

dyld führt die Initialisierer in der shared library aus (denke an statische Initialisierer in C++), und einer davon verursacht die Ausführung der __CFInitialize-Funktion des CoreFoundation-Frameworks. [Ist es möglich, dass dies die erste Sache ist, die CoreFoundation berührt?] Und aus welchem ​​Grund auch immer, __CFInitialize ist nicht glücklich. Dies könnte eine Art fehlende Abhängigkeit sein. Oder es könnte sein, dass der Heap beschädigt ist. Oder es könnte ein latenter Fehler irgendeiner Art im CoreFoundation-Framework sein.

Ich würde vorschlagen, die ersten beiden Möglichkeiten zu trimmen, indem Sie a) mit allen Umgebungsvariablen von DYLD_PRINT_ * arbeiten [siehe man dyld] und b) unter MallocDebug laufen lassen. Wenn keiner von beiden Licht wirft, bleibt wahrscheinlich ein Radar für die CoreFoundation-Leute übrig.

Answer 2

Nach einigen weiteren Problemen und etwas weiterem Googlen fand ich letztendlich die eigentliche Ursache meines Problems.

Man kann nicht eine mit CoreFoundation verknüpfte Bibliothek in einem (Sub-) Thread aufrufen, wenn CoreFoundation überhaupt nicht initialisiert wurde. CFInitialize wird aufgerufen, überprüft scheinbar, ob der Thread der Hauptthread ist und stürzt mit einem SIGTRAP ab.

http://openradar.appspot.com/7209349