क्या “EXC_BREAKPOINT (SIGTRAP)” अपवाद विराम बिंदुओं के कारण हैं?


82

मेरे पास एक मल्टीथ्रेडेड ऐप है जो मेरे सभी परीक्षण मशीनों पर बहुत स्थिर है और मेरे लगभग हर उपयोगकर्ता (क्रैश की कोई शिकायत के आधार पर) के लिए स्थिर लगता है। ऐप एक उपयोगकर्ता के लिए अक्सर क्रैश हो जाता है, हालांकि, जो क्रैश रिपोर्ट भेजने के लिए पर्याप्त था। सभी क्रैश रिपोर्ट (~ 10 लगातार रिपोर्ट) अनिवार्य रूप से समान दिखती हैं:

Date/Time:       2010-04-06 11:44:56.106 -0700
OS Version:      Mac OS X 10.6.3 (10D573)
Report Version:  6

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   com.apple.CoreFoundation        0x90ab98d4 __CFBasicHashRehash + 3348
1   com.apple.CoreFoundation        0x90adf610 CFBasicHashRemoveValue + 1264
2   com.apple.CoreText              0x94e0069c TCFMutableSet::Intersect(__CFSet const*) const + 126
3   com.apple.CoreText              0x94dfe465 TDescriptorSource::CopyMandatoryMatchableRequest(__CFDictionary const*, __CFSet const*) + 115
4   com.apple.CoreText              0x94dfdda6 TDescriptorSource::CopyDescriptorsForRequest(__CFDictionary const*, __CFSet const*, long (*)(void const*, void const*, void*), void*, unsigned long) const + 40
5   com.apple.CoreText              0x94e00377 TDescriptor::CreateMatchingDescriptors(__CFSet const*, unsigned long) const + 135
6   com.apple.AppKit                0x961f5952 __NSFontFactoryWithName + 904
7   com.apple.AppKit                0x961f54f0 +[NSFont fontWithName:size:] + 39

(.... अधिक पाठ इस प्रकार है)

सबसे पहले, मैंने लंबे समय तक [NSFont fontWithName: size:] की छानबीन की। मुझे लगा कि शायद उपयोगकर्ता के फ़ॉन्ट किसी तरह खराब हो गए हैं, इसलिए [NSFont fontWithName: size:] कुछ गैर-मौजूद और उस कारण से असफल होने का अनुरोध कर रहा था। मैंने पहले से फ़ॉन्ट उपलब्धता की जांच करने के लिए [[NSFontManager sharedFontManager] availableFontNamesWithTraits: NSItalicFontMask] का उपयोग करके कोड का एक गुच्छा जोड़ा। अफसोस की बात है कि इन बदलावों ने समस्या को ठीक नहीं किया।

अब मैंने देखा है कि मैं कुछ डिबगिंग ब्रेकप्वाइंट्स को हटाना भूल गया, जिनमें _NSLockError, [NSException raise], और objc_exception_throw शामिल हैं। हालाँकि, सक्रिय बिल्ड कॉन्फ़िगरेशन के रूप में "रिलीज़" का उपयोग करके ऐप निश्चित रूप से बनाया गया था। मुझे लगता है कि "रिलीज़" कॉन्फ़िगरेशन का उपयोग किसी भी ब्रेकप्वाइंट की स्थापना को रोकता है - लेकिन फिर मुझे यकीन नहीं है कि ब्रेकपॉइंट कैसे काम करते हैं या क्या ब्रेकपॉइंट के लिए प्रोग्राम को चलाने के लिए ब्रेकडाउन के लिए कोई प्रभाव पड़ता है या नहीं।

मेरे प्रश्न हैं: क्या मेरे द्वारा छोड़े गए ब्रेकपॉइंट सेट उपयोगकर्ता द्वारा देखे गए क्रैश का कारण हो सकते हैं? यदि हां, तो ब्रेकपॉइंट केवल इस एक उपयोगकर्ता के लिए समस्या का कारण क्यों होगा? यदि नहीं, तो [NSFont fontWithName: size:] के साथ किसी और को भी ऐसी ही समस्या थी?

मैं शायद केवल ब्रेकपॉइंट को हटाने और उपयोगकर्ता को वापस भेजने की कोशिश करूंगा, लेकिन मुझे यकीन नहीं है कि मैंने उस उपयोगकर्ता के पास कितनी मुद्रा छोड़ दी है। और मैं आम तौर पर यह समझना चाहता हूं कि क्या ब्रेकपॉइंट सेट छोड़ने से संभवतः एक समस्या पैदा हो सकती है (जब "रिलीज़" कॉन्फ़िगरेशन का उपयोग करके ऐप बनाया गया है)।

जवाबों:


188

क्या “EXC_BREAKPOINT (SIGTRAP)” अपवाद विराम बिंदुओं के कारण हैं?

नहीं। अन्य तरीके से, वास्तव में: एक SIGTRAP (ट्रेस ट्रैप) डिबगर को आपके प्रोग्राम को तोड़ने (बाधित) का कारण होगा, उसी तरह एक वास्तविक ब्रेकपॉइंट होगा। लेकिन ऐसा इसलिए है क्योंकि डिबगर हमेशा किसी दुर्घटना पर टूटता है, और एक SIGTRAP (कई अन्य संकेतों की तरह ) एक प्रकार का क्रैश है।

SIGTRAPs आम तौर पर NSException द्वारा फेंके जाने के कारण होते हैं, लेकिन हमेशा नहीं - यह सीधे अपने आप को बढ़ाने के लिए भी संभव है ।

अब मैंने देखा है कि मैं कुछ डिबगिंग ब्रेकप्वाइंट्स को हटाना भूल गया, जिनमें _NSLockError, [NSException raise], और objc_exception_throw शामिल हैं।

वे ब्रेकपॉइंट नहीं हैं। उनमें से दो कार्य हैं और -[NSException raise]एक विधि है।

क्या आपका मतलब है कि आप उन कार्यों और उस पद्धति पर ब्रेकपॉइंट सेट करते हैं?

मुझे लगता है कि "रिलीज़" कॉन्फ़िगरेशन का उपयोग किसी भी ब्रेकप्वाइंट की सेटिंग को रोकता है--

नहीं।

कॉन्फ़िगरेशन बिल्ड कॉन्फ़िगरेशन हैं। वे प्रभावित करते हैं कि Xcode आपके एप्लिकेशन कैसे बनाता है।

ब्रेकप्वाइंट बिल्ड का हिस्सा नहीं हैं; आप उन्हें डिबगर में सेट करें। वे केवल मौजूद हैं, केवल हिट हो जाते हैं, और जब आप अपने प्रोग्राम को डिबगर के तहत चलाते हैं तो केवल अपना प्रोग्राम बंद कर देते हैं।

चूंकि वे बिल्ड का हिस्सा नहीं हैं, इसलिए उपयोगकर्ता को अपने ब्रेकपॉइंट को केवल ऐप बंडल देकर पास करना संभव नहीं है।

मुझे यकीन नहीं है कि ब्रेकप्वाइंट कैसे काम करता है ...

जब आपका प्रोग्राम ब्रेकपॉइंट से टकराता है, तो डिबगर आपके प्रोग्राम को तोड़ता है (बाधित करता है), जिससे आप प्रोग्राम की स्थिति की जांच कर सकते हैं और ध्यान से देख सकते हैं कि प्रोग्राम गलत कैसे हुआ।

चूंकि यह डिबगर है जो आपके प्रोग्राम को रोकता है, इसलिए जब आपके प्रोग्राम डिबगर के तहत नहीं चल रहे हों तो ब्रेकप्वाइंट का कोई प्रभाव नहीं पड़ता है।

... या क्या प्रोग्राम को ब्रेकपॉइंट के लिए gbb के भीतर से चलाने की आवश्यकता है, कोई प्रभाव पड़ता है।

ऐसा होता है। डिबगर ब्रेकपॉइंट केवल डीबगर के भीतर काम करते हैं।

मेरे प्रश्न हैं: क्या मेरे द्वारा छोड़े गए ब्रेकपॉइंट सेट उपयोगकर्ता द्वारा देखे गए क्रैश का कारण हो सकते हैं?

नहीं।

सबसे पहले, जैसा कि उल्लेख किया गया है, भले ही ये ब्रेकप्वाइंट किसी भी तरह से उपयोगकर्ता के सिस्टम पर ले जाए, ब्रेकपॉइंट केवल डीबगर में प्रभावी होते हैं। यदि आपका प्रोग्राम डीबगर के अंतर्गत नहीं चल रहा है, तो डीबगर किसी ब्रेकपॉइंट पर नहीं रुक सकता है। उपयोगकर्ता लगभग निश्चित रूप से डिबगर के तहत आपके ऐप को नहीं चला रहा है, खासकर जब से उन्हें क्रैश लॉग मिला है।

यहां तक कि अगर वे इन breakpoints सेट के सभी के साथ डिबगर के तहत अपने अनुप्रयोग चलाने था, एक ब्रेकपाइंट केवल मारा जाता है जब आपके प्रोग्राम पहुँच उस बिंदु हैं, इसलिए इन breakpoints में से एक हो सकता है केवल आग अगर आप या कोको बुलाया _NSLockError, -[NSException raise], या objc_exception_throw। उस बिंदु तक पहुंचना समस्या का कारण नहीं होगा, यह समस्या का एक लक्षण होगा।

और यदि आपने कॉल किए जाने वाले लोगों में से एक के रूप में क्रैश किया, तो आपके क्रैश लॉग में कम से कम एक नाम होगा। यह नहीं है

तो, यह आपके ब्रेकपॉइंट (अलग मशीन, डिबगर शामिल नहीं) से संबंधित नहीं था, और यह एक कोको अपवाद नहीं था - जैसा कि मैंने उल्लेख किया है, कोको अपवाद SIGTRAPs का एक कारण है, लेकिन वे केवल एक ही नहीं हैं। आपने एक अलग सामना किया।

यदि नहीं, तो [NSFont fontWithName: size:] के साथ किसी और को भी ऐसी ही समस्या थी?

कोई रास्ता नहीं है हम बता सकते हैं कि क्या कोई समस्या है जो हम समान हैं क्योंकि आपने क्रैश लॉग को काट दिया है। हमें कुछ भी नहीं पता है कि दुर्घटना किस संदर्भ में हुई थी।

केवल एक चीज जो बाहर काटने के लिए अच्छी है वह है "बाइनरी इमेजेस" सेक्शन, क्योंकि हमारे पास आपका डीएसएमवाई बंडलों नहीं है, जिसका अर्थ है कि हम क्रैश लॉग का प्रतीक करने के लिए उस सेक्शन का उपयोग नहीं कर सकते हैं।

दूसरी ओर, आप कर सकते हैं। मैंने इस उद्देश्य के लिए एक ऐप लिखा ; क्रैश लॉग को इसे खिलाएं, और इसे स्वचालित रूप से dSYM बंडल का पता लगाना चाहिए (आप अपने वितरण, अधिकार वितरित करने वाले प्रत्येक रिलीज़ के लिए dSYM बंडल को रख रहे हैं?) और अपने फ़ंक्शन और विधि नाम को स्टैक ट्रेस में पुनर्स्थापित करें जहां भी आपके कार्य और विधियाँ दिखाई देती हैं।

अधिक जानकारी के लिए, Xcode डिबगिंग गाइड देखें


3
वाह, व्यापक उत्तर के लिए धन्यवाद। • "क्या आपका मतलब है कि आप उन कार्यों पर ब्रेकप्वाइंट सेट करते हैं ..." हां, मेरा यही मतलब है। • "ब्रेकप्वाइंट बिल्ड का हिस्सा नहीं हैं ... वे केवल मौजूद हैं, केवल हिट हो जाते हैं, और जब आप अपने प्रोग्राम को डिबगर के तहत चलाते हैं तो केवल अपना कार्यक्रम रोकें" धन्यवाद, यह वही है जो मैं जानना चाहता था। • "दुर्घटना लॉग का प्रतीक ... मैंने इस उद्देश्य के लिए एक ऐप लिखा है" नाइस ऐप। मैं आमतौर पर सरासर अंतर्ज्ञान द्वारा "प्रतीक" करता हूं - लेकिन आपका ऐप एक बेहतर तरीका है! • मैंने निष्कर्ष निकाला है कि यह उपयोगकर्ता के फ़ॉन्ट के साथ किसी प्रकार की समस्या है और उस दृष्टिकोण से इस पर काम करेगा।
डेनिस

7

यह अत्यधिक संभावना है कि इस उपयोगकर्ता के पास एक भ्रष्ट फ़ॉन्ट स्थापित है। स्टैक ट्रेस निश्चित रूप से उस परिकल्पना का समर्थन करता है, जैसा कि यह तथ्य है कि यह केवल एक उपयोगकर्ता को प्रभावित कर रहा है।

ऐप्पल के कोड में गहराई से होने वाले क्रैश को हटाने के लिए उपयोगकर्ता को प्राप्त करने के अलावा आप उस मामले में बहुत कुछ नहीं कर सकते हैं।

फ़ॉन्ट बुक में फ़ॉन्ट सत्यापन चलाने के लिए उपयोगकर्ता प्राप्त करने का प्रयास करें। ऐसा करने के लिए, फ़ॉन्ट बुक लॉन्च करें, स्रोत सूची में सभी फ़ॉन्ट्स पर क्लिक करें और फिर सभी सूचीबद्ध फ़ॉन्ट चुनें। फिर आप फ़ाइल मेनू से मान्य फ़ॉन्ट्स का चयन कर सकते हैं ।


1
फॉन्ट बुक के बारे में इस टिप के लिए धन्यवाद - मैं फोंट के बारे में बहुत कम जानता हूं और वास्तव में मेरे खुद के फोंट को सत्यापित करने का एक दिलचस्प समय था ... मैं सुझाव दूंगा कि उपयोगकर्ता यह कोशिश करते हैं।
डेनिस

0

ब्रेकप्वाइंट बाइनरी के लिए नहीं लिखे गए हैं। ऑड्स अच्छे हैं कि इस व्यक्ति का टूटा हुआ ओएस इंस्टॉलेशन है। Dyld संदेशों के लिए कंसोल लॉग की जाँच करें।


इस तेजी से जवाब के लिए धन्यवाद! इस समस्या के आसपास के Googling में मैंने देखा है कि दूसरों के पास dyld संदेशों के साथ जुड़े EXC_BREAKPOINTS हैं - लेकिन मेरे क्रैश लॉग में dyld के कोई संदेश नहीं दिखाए गए हैं।
डेनिस

0

मेरी भी यही त्रुटि थी। एक अस्पष्ट कारण के लिए ब्रेकपाइंट EXC_BREAKPOINT अपवाद को फेंकने के लिए जिम्मेदार था । समाधान ब्रेकपॉइंट को हटाने के लिए था, और फिर कोड काम करता है।

EXC_BREAKPOINT एक प्रकार का अपवाद है जिसका उपयोग डिबगर करते हैं। जब आप अपने कोड में एक ब्रेकपॉइंट सेट करते हैं, तो कंपाइलर निष्पादन योग्य कोड में इस प्रकार का एक अपवाद सम्मिलित करता है। जब निष्पादन उस बिंदु तक पहुंचता है, तो अपवाद को फेंक दिया जाता है और डिबगर इसे पकड़ लेता है। तब डीबगर "ब्रेकपॉइंट" पंक्ति में आपका कोड दिखाता है। यह कैसे डिबगर काम करता है। लेकिन इस मामले में डीबगर अपवाद को सही ढंग से नहीं संभालता है और इसे नियमित अपवाद त्रुटि के रूप में प्रस्तुत किया जाता है।

मैंने अपने जीवन में दो बार यह त्रुटि पाई है:

  • एक Xcode का उपयोग लगभग एक साल पहले।
  • लगभग 15 साल पहले विजुअल C ++ का उपयोग करने वाला दूसरा।

यह अजीब है, कि मुझे बिना किसी ब्रेक पॉइंट के यह त्रुटि मिली है।
केलीन

मैं यह नहीं बताता कि यह त्रुटि केवल ब्रेकप्वाइंट के साथ होती है: EXC_BREAKPOINT कई कारणों से हो सकता है। मैं जो समझा रहा हूं वह बहुत ही अनियंत्रित मामलों की एक जोड़ी है जहां एक ब्रेकप्वाइंट एक अखंड अपवाद उत्पन्न करता है।
वलादन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.