2010-08-05 20 views
7

पर डब्लॉपन के माध्यम से लाइब्रेरी खोले जाने पर एक क्रैश को डिबग करना मुझे एक सी ++ एप्लिकेशन के साथ समस्या है जो मैंने विकसित किया है जो उपयोगकर्ता द्वारा विकसित पुस्तकालयों को लोड करने के लिए डलोपेन का उपयोग करता है। आवेदन पिछले कुछ वर्षों में विभिन्न प्रकार के लिनक्स डिस्ट्रोज़ और ओएसएक्स के संस्करणों पर विभिन्न लोगों द्वारा उपयोग किया गया है और इसलिए मुझे लगता है कि मेरा उपयोग डलोपेन ठीक है और इसी तरह कोड है जो इस पर निर्भर करता है (हाँ, यह हब्रिज़ है, इसलिए जब यह विफल हो जाता है तो मैं वापस रिपोर्ट करूंगा)। अब मेरे पास समस्या यह है कि एक उपयोगकर्ता ने एक पुस्तकालय विकसित किया है जो मेरे सिस्टम (ओएसएक्स 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 

(मैं पूरी लॉग पोस्ट कर सकते हैं अगर जरूरत है, लेकिन यह मुख्य पाठ सीमा अगर मैं अपनी पोस्ट में शामिल अधिक है)

में टर्मिनल जहां मैं निष्पादन योग्य चला रहा हूं क्रैश अधिसूचना को छोड़कर कोई आउटपुट उत्पन्न नहीं करता है कि निष्पादन योग्य चलाने वाली स्क्रिप्ट ने सिग्नल फंस लिया है।

मेरा प्रश्न इस दुर्घटना के कारण होने पर मुझे और जानकारी कैसे मिल सकती है? अगर कोई संभावित समाधान सुझा सकता है, तो मैं भी खुश हूं, लेकिन शुरू करने के लिए मैं कम से कम जानना चाहता हूं कि सिस्टम वास्तव में गलत क्या है, इस बारे में अधिक जानकारी उत्पन्न करने के लिए।

यदि मैं लाइब्रेरी पर ओटोल चलाता हूं जिसे प्रारंभ में डलोपेन द्वारा खोला जा रहा है तो सब कुछ ठीक दिखता है (कोई लापता लिंक, प्रतीकों इत्यादि)। मेरा मुख्य संदेह यह है कि यह पुस्तकालयों का विशेष संयोजन है जिसे लाइब्रेरी लोड किया जा रहा है जिसके खिलाफ इस दुर्घटना का कारण बन रहा है। इन अन्य पुस्तकालयों को लोड किया जा सकता है जो इन लिंक्ड-विरुद्ध पुस्तकालयों के विभिन्न सबसेट का उपयोग करते हैं। रिकॉर्ड के लिए पुस्तकालयों में एक्स 11, ज़ीरोक का आइस, प्लेयर/स्टेज और ओपनसीवी शामिल है (बाद वाले 2 मैकपॉर्ट्स का उपयोग कर स्थापित निर्भरताओं के साथ मैन्युअल रूप से संकलित)। ऐसा लगता है कि यह ओपनसीवी को शामिल करना है जो समस्या का कारण बनता है, क्योंकि अन्य पुस्तकालय जो ओपनसीवी को छोड़कर इन सभी को लिंक करते हैं, उन्हें कोई समस्या नहीं हो सकती है। ये मेरे संदेह हैं, लेकिन मुझे वर्तमान में जांच की कमी है कि आगे की जांच कैसे करें।

धन्यवाद! निक

अद्यतन: कैलिन के उत्तर (DYLD_PRINT_ * विकल्प जिन्हें मैं पहले से अवगत नहीं था) के लिए धन्यवाद, मैं कम से कम पुष्टि करने में सक्षम था कि कुछ भी पूरी तरह से स्पष्ट नहीं हो रहा था। डीबग जानकारी का उपयोग करके मैं समस्या को एक विशेष पुस्तकालय में कम करने में सक्षम था जो दुर्घटना का कारण बन रहा था। यह पता चला कि यह लाइब्रेरी (libdc1394 ओपनसीवी में libhighgui के माध्यम से मेरे ऐप में जुड़ा हुआ है) CoreServices के खिलाफ सही ढंग से जुड़ा नहीं था और यह दुर्घटना का कारण बन रहा था। किसी कारण से त्रुटि को अन्य चीजों से छुपाया गया था, जिससे अंतिम दुर्घटना हुई थी। Libdc1394 समस्या पर जानकारी के लिए, here देखें। दुर्भाग्यवश मैं एक साफ फिक्स नहीं कर सका जिसे मैं यहां रिपोर्ट कर सकता हूं, इसलिए बस उस ऐप का एक संस्करण प्राप्त करने में कामयाब रहा जो डोडी लाइब्रेरी से लिंक नहीं हुआ (ओपनसीवी संकलन में libdc1394 को बंद करके)।

उत्तर

3

डाइल्ड साझा लाइब्रेरी में प्रारंभकर्ताओं को चला रहा है (सी ++ में स्थिर प्रारंभिक सोचें), और उनमें से एक कोरफॉउंडेशन फ्रेमवर्क के __CFInitialize फ़ंक्शन को चलाने के लिए कारण बन रहा है। [क्या यह संभव है कि कोरफॉउंडेशन को छूने वाली यह पहली बात है?] और किसी भी कारण से, __CFInitialize खुश नहीं है। यह किसी प्रकार की लापता निर्भरता हो सकती है। या यह ढेर भ्रष्ट हो सकता है। या यह CoreFoundation ढांचे में किसी तरह का एक गुप्त बग हो सकता है।

मैं पहले दो संभावनाओं को ट्रिम करने का सुझाव दूंगा) सभी DYLD_PRINT_ * पर्यावरण चर सेट [man dyld] देखें और बी) MallocDebug के अंतर्गत चल रहा है। यदि उनमें से कोई भी प्रकाश किसी भी प्रकाश को नहीं छोड़ता है, तो शायद कोरफॉउंडेशन लोगों को देखने के लिए आपको रडार लिखने के साथ छोड़ दिया गया है।

+0

बहुत बढ़िया है, धन्यवाद। मैं इन दोनों को आजमाउंगा और देखूँगा कि क्या होता है। मैं भविष्य में संदर्भ के लिए जो भी ढूंढता हूं उसे वापस पोस्ट करूंगा। –

7

कुछ और समस्याओं के बाद और कुछ और Googling मुझे अंततः मेरी समस्या का असली कारण मिला।

कोई कोरफॉउंडेशन को पहले स्थान पर प्रारंभ नहीं किया गया था, तो एक (उप) थ्रेड में CoreFoundation से जुड़ी लाइब्रेरी को कॉल नहीं कर सकता। CFInitialize कहा जाता है, स्पष्ट रूप से जांचता है कि धागा मुख्य धागा है और यदि यह नहीं है, तो सिगट्रैप के साथ दुर्घटनाग्रस्त हो जाता है।

http://openradar.appspot.com/7209349