🙍 🐯 👍🏼 एक क्रैश और NSLog की कहानी जिसने उसका इलाज किया 🌬️ 👩🏻‍🤝‍👨🏽 🧑🏼‍🤝‍🧑🏻

मैं क्रैश और NSLogs का इलाज कर रहा हूं। सस्ती। कई वर्षों का अनुभव। 100% गारंटी।

इस शीर्षक जैसी किसी चीज़ के साथ, मेरी परियोजनाओं में से साढ़े तीन महीने पहले जो कुछ हुआ, उसका वर्णन कर सकता हूं। बल्कि, यह मेरी परियोजना भी नहीं थी, लेकिन मुझे दुर्घटना की समस्या से निपटना पड़ा।

यह सब इस तथ्य के साथ शुरू हुआ कि अपेक्षाकृत बड़ी परियोजनाओं में से एक पर, उपयोगकर्ता प्राधिकरण के दौरान एक अपवाद गिरना शुरू हो गया। “अच्छा, यह क्या है? हर कोई होता है। वे शून्य पर चेक लगाना भूल गए या कहीं गड़बड़ हो गई। ", मेरे लिए, बड़ी घटना परियोजना पर दुर्घटना है," अधिकांश प्रोग्रामर सोचेंगे। सिद्धांत रूप में, मैं बिल्कुल सहमत हूं। आईफोन के लिए प्रोग्रामिंग में क्रैश ऐसी दुर्लभ घटना नहीं है, और आप दिन में दस बार आते हैं। लेकिन यह एक विशेष था। जब उन्हें उनके बारे में कुछ मापदंडों और विशेषताओं के बारे में बताया गया, तो उन्हें पहले ही "जादू" की गंध आने लगी:

सिम्युलेटर प्रजनन क्षमता : 100%
डिवाइस पर प्लेबिलिटी : 0%
क्रैश पथ (क्रैश स्थानीयकरण के बाद): ~ 40 सेकंड
संकलन अनुकूलन सेटिंग्स (-O1, -O2 ...) प्रतिलिपि प्रस्तुत करने योग्यता को प्रभावित नहीं करती हैं
XIB का उपयोग प्रोजेक्ट में नहीं किया जाता है

हाँ, वह बहुत हानिरहित दिख रहा था:

// Code UITextView * textView = [ [UITextView alloc] initWithFrame:CGRectMake(0, 150, _width, _height)]; // Exception *** Terminating app due to uncaught exception 'CALayerInvalidGeometry', reason: 'CALayer bounds contains NaN: [0 0; nan 200]'

"ठीक है, ठीक है, हेजहोग उस चौड़ाई को समझता है - गणना करने के बाद - NaN!", मैंने सोचा कि देखने की चौड़ाई कहाँ और कैसे गणना की जाती है, और त्वरित रूप से खतरनाक कुछ भी नहीं मिल रहा है, मैं इसकी पुष्टि करने के लिए दृश्य बनाकर NSLog सेट करता हूं। और इसके अलावा, तत्व के निर्माण के साथ लाइन पर एक विराम बिंदु।

 // Source: NSLog(@"width = %f", _width); //Output: width = 200

"उम," मैंने खुद को सोचा, और ब्रेकपॉइंट के बाद कार्यक्रम चलाना जारी रखा। और दुर्घटना नहीं हुई ...

टेस्ट प्रोजेक्ट जिसमें यह क्रैश पुन: पेश किया जाता है

उन लोगों के लिए जो स्वयं इस जानवर को देखने में रुचि रखते हैं - एक परीक्षण परियोजना मेरे साथ है ।
यह विशेष रूप से आईओएस सिम्युलेटर, संस्करण एसडीके 5.1 (एसडीके 6+ पर) पर नहीं चलाया जाता है, लेकिन अगर ऐसे लोग हैं जो पुन: पेश करेंगे - पीएम को लिखें, इसे पोस्ट करें)

यदि आप अभी भी सोचते हैं कि यहां कुछ तुच्छ है, तो शांति से पढ़ें। जब हम मज़े के लिए आते हैं, तो मैं रुक जाता हूं और बिगाड़ने वालों के बारे में चेतावनी देता हूं।

मैंने क्या किया है?

यदि आप तार्किक रूप से सोचते हैं, तो सब कुछ स्पष्ट हो जाता है। चूंकि दुर्घटना गायब हो गई, यह इसलिए है क्योंकि मैंने कुछ बदल दिया (क्योंकि इससे पहले, प्रतिलिपि प्रस्तुत करने योग्यता 100% थी)। सवाल केवल वही था जो वास्तव में बदल गया था ।

मैंने दृश्य बनाने से पहले कुछ कोड जोड़े
मैंने NSLog जोड़ा
मैंने धारा रोक दी
मैंने पैरामीटर के रूप में इसे पास करने से पहले, वर्ग चर _width को एक्सेस किया
....

यदि आपके पास अभी भी विचार हैं कि मैं क्या बदल सकता हूं - आप लिख सकते हैं। फिर जांचें कि क्या अनुमान सही थे। लेकिन, सबसे अधिक संभावना है - शायद ही;)

सभी आइटम आसानी से जांचे जाते हैं। मैंने सभी बदलावों को हटा दिया और प्रयोग करना शुरू कर दिया।

मैंने धारा रोक दी

यहां विचार काफी सरल है। बहुधा - त्रुटि मल्टीथ्रेडिंग के कारण होती है।
यह जांचना सबसे आसान था, मैंने NSLog 'a' के बिना एक ब्रेकपॉइंट सेट किया। कोड क्रैश होना जारी रहा, उसी 100% के साथ।

मैंने कक्षा के चर को एक्सेस किया है। दृश्य बनाने से पहले मैंने कुछ कोड जोड़े हैं

इन बिंदुओं का विचार कोड जनरेशन के "फीचर्स" में है, जो चमत्कारिक रूप से अप्रत्याशित परिणाम पैदा कर सकता है।
टैम्बोरिन और अतिरिक्त, बेतरतीब ढंग से उत्पन्न के साथ कोई नृत्य नहीं, चर के लिए कोड की पहुंच के साथ _width परिणाम नहीं देते थे। एप्लिकेशन लगातार क्रैश हो गया।

मैंने NSLog जोड़ा

"नहीं, ठीक है, तुम गंभीर नहीं हो, क्या तुम हो?"
यह गंभीरता से निकला। NSLog ने क्रैश को "ठीक" करना जारी रखा। स्थिर। भले ही इसके लिए कितने भी पैरामीटर्स पास किए गए हों। अधिक उल्लेखनीय विशेषताओं की खोज की गई। अनुप्रयोग क्रैश होना जारी रहा, भले ही आपने पैरामीटर के रूप में _width , _height का उपयोग नहीं किया हो। NSLog के बिना , (-) initWithFrame - को दिए गए कोई भी मान : एक ही त्रुटि के साथ एप्लिकेशन को क्रैश कर देगा । अन्य बातों के अलावा, यह पता चला है कि NSLog को दृश्य के सामने रखना आवश्यक नहीं था। इसे उस पद्धति की शुरुआत में रखा जा सकता है, जहां दृश्य बनाया गया था ... या उस विधि में जिसे इस विधि कहा जाता है ... या यहां तक कि उस विधि को भी कहा जाता है जिसे ... कहा जाता है, आप सामान्य रूप से समझते हैं। मुख्य बात यह है कि निर्माण से पहले।

सफलता!

यह बात है। समस्या "हल हो गई थी।" अवरोधक को समाप्त कर दिया जाता है, और कुछ भी आपको सिम्युलेटर पर एप्लिकेशन को शांति से परीक्षण करने से रोकता है। और इसके अलावा, बहुत से काम थे जिन्हें करने की आवश्यकता थी, और मुझे इसे बदलना पड़ा।

क्या समस्या हल हो गई है?

इस सवाल ने मुझे कई शामों तक परेशान किया, जबकि मैं मुख्य परियोजना को पूरा कर रहा था। क्या समस्या का समाधान हो गया है, या NSLog के साथ "इलाज" बस कुछ बड़ी समस्या के लक्षणों को दूर करता है जो कि लर्क और प्रोजेक्ट के रिलीज होने का इंतजार करता है? और फिर, जब हर कोई इसके बारे में भूल जाता है, और इसके निर्धारण के लिए AppStore में जमा के लिए एक सप्ताह इंतजार करना आवश्यक होगा, क्या यह स्वयं प्रकट होगा और सब कुछ तोड़ना और नष्ट करना शुरू कर देगा, लेकिन सिम्युलेटर पर नहीं?

जादू?

एक ओर, मैंने समझा कि समस्याएं मेरे कोड में थीं। और, सबसे अधिक संभावना है, यह एक UIKit पुस्तकालय त्रुटि नहीं है । परिचित प्रोग्रामर ने कहा - अपने कोड में एक समस्या की तलाश करें। और मैं उनसे सहमत था। लेकिन उसकी तलाश कैसे करें? परियोजना बल्कि बड़ी है, कई लाइनों में समस्या को स्थानीय बनाने के प्रयास विफल हो जाते हैं। मैं सब कुछ छोड़ना चाहता था, "जादू" और स्कोर। और परियोजना में जादू की भावना के साथ रहते हैं। और फिर, क्योंकि, यदि आप जानते हैं कि जादू कैसे काम करता है, तो कोई भी रुचि खो जाती है, प्रलेखन के अनुसार सब कुछ सामान्य हो जाता है।

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

जादू का जादू

उस पल में, मैं दुर्घटनाग्रस्त स्थल के लिए एक स्टैकट्रेस था। समस्या उसके अंदर कहीं थी, अच्छी तरह से, या कुछ इस तथ्य के कारण कि यह सब सुरक्षित रूप से गिर गया।

 #4 0x01d8b04a in -[CALayer setBounds:] () <---- NaN lives here #5 0x02d1d714 in WebCore::TileGrid::updateHostLayerSize() () #6 0x02d1af26 in WebCore::TileCache::TileCache(WAKWindow*) () #7 0x02d52507 in -[WAKWindow initWithLayer:] () #8 0x002ee5e9 in -[UIWebTiledView initWithFrame:] () #9 0x001af9b5 in -[UIWebDocumentView initWithWebView:frame:] () #10 0x001af89e in -[UIWebDocumentView initSimpleHTMLDocumentWithStyle:frame:preferences:groupName:] () #11 0x0012cb6a in -[UITextView commonInitWithWebDocumentView:isDecoding:] () #12 0x0012bf0e in -[UITextView initWithFrame:] ()

Dtrace के लिए एक अपेक्षाकृत सरल स्क्रिप्ट का उपयोग करते हुए , मैं यह पता लगाने में सक्षम था कि बीमार एफएएन कहां दिखाई देता है। यह पता चला है कि पैरामीटर बहुत अंत में "खो गए" हैं:

 QuartzCore`-[CALayer setBounds :] <------ (0, 0, NaN, height) WebCore`WebCore::TileGrid::updateHostLayerSize()+0x140 WebCore`WebCore::TileCache::TileCache(WAKWindow*)+0x1c6 WebCore`-[WAKWindow initWithLayer:]+0xd7 UIKit`-[UIWebTiledView initWithFrame:]+0xec " <------ (0, 0, width, height)" UIKit`-[UIWebDocumentView initWithWebView:frame:]+0xb5 UIKit`-[UIWebDocumentView initSimpleHTMLDocumentWithStyle:frame:preferences:groupName:]+0xfe UIKit`-[UITextView commonInitWithWebDocumentView:isDecoding:]+0x198 UIKit`-[UITextView initWithFrame:]+0x70 " <------ (0, 0, width, height)"

क्या करें? जाहिर है समस्या हमारे कोड में नहीं है! आत्म-महत्व के एक बढ़े हुए अर्थ के साथ, मैं पहले से ही Apple को एक बग रिपोर्ट भेजने की तैयारी कर रहा हूं। और मैं यह देखने के लिए चढ़ता हूं कि स्टैक वहां कैसे कर रहा है।

स्पॉयलर अलर्ट!

यदि आप अभी भी इस समस्या को स्वयं हल करने जा रहे हैं, तो यह लेख पढ़ने से रोकने का समय है;)
उन लोगों के लिए जो इसे स्वयं पता लगाने जा रहे हैं, और सोचते हैं कि समस्याएं स्टैक के साथ काम करने में झूठ बोलती हैं, या इसके विपरीत, वे सोचते हैं कि समस्याएं स्टैक से संबंधित नहीं हैं, एक छोटा स्पॉइलर

मुझे मत पढ़ो!

समस्या सभी से संबंधित नहीं है

ढेर परेशानियाँ?

Xcode में कैसे देखें कि वर्तमान में स्टैक में क्या चल रहा है? फ़ंक्शन को कौन से पैरामीटर पास किए जाते हैं? वे कैसे संचरित होते हैं और किन नियमों से होते हैं? और स्टैक के माध्यम से?
यह उन सवालों का सिर्फ एक छोटा सा हिस्सा है जिसका उस समय मेरे पास कोई जवाब नहीं था, लेकिन डार्कप्रोगर ने फिर से मदद की (सामान्य तौर पर, वोवा ने बहुत लगन और धैर्य से सुनी, या सुनने का नाटक किया, मेरे सभी भ्रम और कारण और प्रभाव के बहुत विचार नहीं;) एक बहुत ही उपयोगी दस्तावेज में मेरी नाक को दबाकर। और अधिक विशिष्ट होने के लिए, फिर इसके एक विशिष्ट भाग के लिए । तकनीकी के त्वरित पढ़ने के बाद, मैं स्टैक की सामग्री को प्रदर्शित करने में कामयाब रहा।

हालांकि, इन आंकड़ों से मेरी समझ में मदद नहीं मिली कि क्या हो रहा है। तथ्य यह है कि स्टैक दोनों मामलों में समान था। कोई फर्क नहीं। स्मृति में सभी मान बिल्कुल समान थे और स्टैक रजिस्टर समान मेमोरी पतों के लिए संदर्भित थे। कई बार जांच की गई, एप्लिकेशन को पुनः आरंभ किया, मेमोरी पतों की जांच की restart। सब कुछ संयोग से।

आगे क्या है?

जैसा कि मैंने कहा, मेमोरी एड्रेस में सभी मान मेल खाते हैं। लेकिन फिर भी कुछ अलग था। कुछ अलग था। सच है, इस "कुछ" के लिए खोज अस्थायी रूप से पृष्ठभूमि में फीका हो गई - मुझे बीमार नट का पता चला ।

यह FPU प्रोसेसर के सेंट रजिस्टरों में से एक में स्थित था। चूंकि मुझे नहीं पता था कि ये रजिस्टर क्या थे, इसलिए मुझे इंटेल से प्रलेखन में चढ़ना पड़ा। प्रलेखन के अनुसार, रजिस्टर ग्रुप st0-st7 FPU के लिए एक चक्रीय ढेर है, जिसके माध्यम से प्रोसेसर फ्लोटिंग संचालन कार्यों के लिए जिम्मेदार है। सब कुछ साफ होने लगा। कोई व्यक्ति एफपीयू में स्टैक पर NaN मान डालता है, और फिर ऑपरेशन के परिणामस्वरूप इसे हटा देता है। यह केवल यह पता लगाने के लिए रहता है कि यह कौन करता है।

लगभग एक घंटे मैंने जादू के एक टुकड़े पर मार दिया जो अचानक दिखाई दिया, जिसे एक सरल द्वारा समझाया गया था "ध्यान से प्रलेखन पढ़ें।" यह जादू इस प्रकार प्रकट हुआ। " Fstp " निर्देश ने गलत तरीके से काम किया (पृष्ठ 190)। कमांड को निम्नलिखित ऑपरेशन करना चाहिए: st0 स्टैक के FPU के ऊपर से वर्तमान मान लें, इसे निर्दिष्ट पते पर लिखें (मेरे मामले में, $ ebp-0x64 में ), और FP स्टैक से मान को धक्का दें।
लेकिन केवल इस निर्देश को पूरा करने के बाद, $ ebp + 0x64 0 हो गया, इसके बजाय मूल्य 320 मुझे चाहिए था।

Fstp कमांड को निष्पादित करने से पहले

Fstp कमांड को निष्पादित करने के बाद

चौकस विशेषज्ञ शायद पहले से ही समस्या को देखते हैं। जो लोग इस व्यवहार को स्वयं सत्यापित करना चाहते हैं, वे परीक्षण परियोजना को डाउनलोड कर सकते हैं और वेबकोर :: टाइलग्रिड :: updateHostLayerSize () फ़ंक्शन पर एक विराम बिंदु डाल सकते हैं। अंदर यह सही टुकड़ा खोजने के लिए काफी आसान है। जो कोई भी मेरी प्लगिंग के कारण में रुचि रखता है - बिगाड़ने के लिए स्वतंत्र महसूस करें।

और $ ebp-0x64, वे कहते हैं, असली नहीं है!

इसका कारण डेटा प्रकार हैं। Fstp कमांड मेमोरी को 40-बिट फ्लोटिंग-पॉइंट नंबर लिखता है, जिसे आमतौर पर आम लोगों में लंबे समय तक डबल के रूप में संदर्भित किया जाता है। इस उदाहरण में, डिबगर में, मैं सही पते को देखता हूं, लेकिन मैं केवल 40 बिट्स नहीं, बल्कि 32 बिट्स दिखाता हूं। जब मैंने सही डेटा प्रकार का संकेत दिया तो सब कुछ ठीक हो गया। एक त्रुटि जो मुझे खोजने में आधे घंटे का समय लेती है अगर मैं प्रलेखन को अधिक ध्यान से पढ़ता तो शायद ऐसा नहीं होता। नैतिक: प्रलेखन पढ़ें। यह उपयोगी है और समय बचाता है।

ढेर अतिप्रवाह?

के बाद मैं fstp , और बड़ी समझ से बाहर। मैंने फिर से मतभेद ढूंढना शुरू कर दिया। और जब से मुझे पहले से ही पता था कि कारण स्टैक से संबंधित नहीं है, मैंने प्रोसेसर रजिस्टरों के मूल्यों पर ध्यान केंद्रित किया। और मतभेद थे। और यह भी स्पष्ट हो गया कि NaN कहाँ से आता है। सबसे पहले, मैंने $ ftag रजिस्टर को देखा, जिसके मूल्य ने तुरंत मुझे FPU रजिस्टरों के ढेर में कुछ खराब होने की उपस्थिति के बारे में बताया (पृष्ठ 182)।

यह, निश्चित रूप से, $ st0- $ st7 को देखकर मनाया जा सकता है, लेकिन $ ftag आपको यह पता लगाने की अनुमति देता है कि वर्तमान में रजिस्टरों में कौन से राज्य हैं - जिनका उपयोग किया जाता है, जो व्यस्त हैं, और जो खाली हैं। उदाहरण से पता चलता है कि सभी रजिस्टर व्यस्त (वैध) हैं, और उनमें से केवल एक में कुछ विशेष है।

लेकिन आखिरकार, जब मैं $ fstat रजिस्टर (x87 FPU रजिस्टर, पी। 178) के मूल्यों को देखा तो जादू के बारे में सभी प्रश्न दूर हो गए।

ढेर अतिप्रवाह

FPU प्रोसेसर रजिस्टर में ढेर अतिप्रवाह। वास्तव में अपने आप ढेर हो जाना किसी अपवाद का कारण नहीं बनता है, और बस नियंत्रण शब्द में एक ध्वज सेट करता है जो एक अपवाद हुआ है।

यदि अमान्य-ऑपरेशन अपवाद को नकाबपोश किया जाता है, तो x87 FPU फ़्लोटिंग पॉइंट, पूर्णांक या पैक किए गए दशमलव पूर्णांक को गंतव्य संचालक के लिए अनिश्चित मान लौटाता है, जो निष्पादित होने वाले निर्देश पर निर्भर करता है। यह मान ओवर-इंस्टॉलेशन द्वारा निर्दिष्ट गंतव्य रजिस्टर या मेमोरी लोकेशन को लिखता है।

लेकिन, यदि हम अमान्य राज्य के साथ रजिस्टर के मूल्य का उपयोग करते हैं, तो हमें NaN प्राप्त होता है, जो कि एक बार मेमोरी में, एक पैरामीटर के रूप में आता है, जब CALayer बनाते हैं।

इसलिए, मैं समस्या के सबसे निचले स्तर पर चला गया। मुझे पता था कि जादू NaN कहां से आता है, कार्यक्रम में, और FPU स्टैक रजिस्टरों में स्टैक ओवरफ्लो के बारे में। यह सिर्फ जवाब है, जहां और जब ऐसा होता है मेरे पास नहीं था। मेरे दिमाग में यह विचार फिर से पैदा हो गया था कि यह UIKit के साथ खिलवाड़ करता है , लेकिन आप बिना सबूत के दावा नहीं कर सकते। दूसरी ओर, मुझे नहीं पता था कि कोड एफपीयू स्टैक ओवरफ्लो कैसे कह सकता है (जो मैंने उस दिन के बारे में सीखा था)।

अपराधी

अपेक्षाकृत कम समय के लिए, एक फ़ंक्शन को फिर भी स्थानीयकृत किया गया था, जो कि हुई हर चीज का अपराधी था। यहाँ वह है, जो कुछ भी होता है उसका अपराधी!

 // ACLabel : UILabel - (CGFloat)resizeToContents { CGSize size = [self.text sizeWithFont:self.font forWidth:self.frame.size.width lineBreakMode:self.lineBreakMode]; CGRect oldFrame = self.frame; oldFrame.size.height = size.height; self.frame = oldFrame; return size.height; }

कुछ डरावना खोजने की कोशिश कर रहा है? कोशिश करें। मैंने भी कोशिश की। लंबे और थकाऊ। मैंने विधि को फिर से लिखा, इसका नाम बदल दिया, इसे एक श्रेणी बना दिया। और सब व्यर्थ। इस विधि ने FPU Stack'e में कचरा छोड़ दिया। इसके अलावा, जादू ने एक नया रूप ले लिया है। उसी विधि ने हर बार कचरे को ढेर में छोड़ दिया। यही है, "कभी-कभी" विधि सामान्य रूप से "स्टैक के शीर्ष से मान" लेती है, और कभी-कभी वह पूरी तरह से इसके बारे में भूल जाती है, और इसे अनदेखा करती है, जिससे दुर्घटना का अनुमान लगाया जाता है। तो इस कोड में क्या गलत है?

IA-32 आर्किटेक्चर पर आधारित प्रणालियों पर, जब कोई एप्लिकेशन एक फ़ंक्शन को कॉल करता है जो फ्लोटिंग-पॉइंट वैल्यू देता है, तो फ़्लोटिंग-पॉइंट मान फ़्लोटिंग-पॉइंट स्टैक के शीर्ष पर माना जाता है। यदि रिटर्न वैल्यू का उपयोग नहीं किया जाता है, तो कंपाइलर को फ्लोटिंग-पॉइंट स्टैक का मान पॉप करना चाहिए ताकि फ्लोटिंग-पॉइंट स्टैक को सही स्थिति में रखा जा सके।

"मैं इससे कैसे छुटकारा पा रहा हूँ!" (व्यंग्य)। अब गिल्ट वेक्टर आसानी से UIKit 'और फिर से संकलक में स्थानांतरित हो गया है। आखिरकार, उसे FPU स्टैक से मूल्य को हटा देना चाहिए! एक चाहिए, लेकिन नहीं। बल्कि, यह करता है ... लेकिन हमेशा नहीं। तो कब?

एक कदम जीत का

और मैं आपके लिए इस सवाल का जवाब दूंगा। लेकिन पहले, मेरे पास एक छोटा सा सवाल है: "क्या उदाहरण में दर्शाई गई लाइनें समान हैं?"

 //     //  №1 [obj someMethod]; //  №2 [obj perfromSelector:@selector(someMethod)];

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

PerformSelector: विधि रिसीवर को सीधे aSelector संदेश भेजने के बराबर है। उदाहरण के लिए, निम्नलिखित तीनों संदेश समान कार्य करते हैं:

 id myClone = [anObject copy]; id myClone = [anObject performSelector:@selector(copy)]; id myClone = [anObject performSelector:sel_getUid("copy")];

। ऑब्जेक्ट के अलावा कुछ भी लौटाने वाले तरीकों के लिए, NSInvocation का उपयोग करें।

जब लीड बोल्ड होती है, तो, ज़ाहिर है, वे इसे नोटिस करते हैं। प्रलेखन स्पष्ट रूप से संकेत देता है कि अगर अचानक एक विधि को आईडी के अलावा कुछ और वापस करना चाहिए, तो हमें NSInvocation का उपयोग करने की आवश्यकता है। लेकिन मैं कहूंगा कि अगर आप एक वस्तु नहीं लौटाते हैं, तो भी सब कुछ काम करता है। यह वैसे भी काम किया। उस दुर्दिन तक।

लाभ

शायद, कई लोग पहले ही अनुमान लगा चुके हैं कि यहां क्या हो रहा है। सब कुछ काफी सरल है (विशेष रूप से लेख पढ़ने के बाद, अच्छी तरह से, या ढाई दिनों के खेल के साथ dtrace, डिबगर, प्रलेखन में खुदाई करना और इसी तरह)।

कंपाइलर एक ऐसी विधि देखता है जो फ्लोट को वापस करना चाहिए, और सही ढंग से कोड उत्पन्न करता है, जो विधि को कॉल करने के बाद, एफपीयू स्टैक से लौटे मूल्य को हटा देता है।
PerformSelector विधि का उपयोग करने के मामले में, कंपाइलर को यह नहीं पता होता है कि विधि क्या लौटाती है, इसलिए यह प्रोग्रामर के अच्छे विश्वास के लिए उम्मीद करता है - वह मानता है कि विधि id वापस कर देगी।
यदि कोड एक विधि के लिए performSelector का उपयोग करता है जो एक फ्लोट को वापस करना चाहिए (भले ही आप लौटे परिणाम का उपयोग न करें), तो कंपाइलर को यह नहीं पता है कि आपको FPU स्टैक से लौटाया गया मान निकालने की आवश्यकता है। इसलिए, performSelector के माध्यम से रिटर्न-फ्लोट विधि के लिए प्रत्येक कॉल के साथ, FPU स्टैक रजिस्टरों में से एक "क्लॉग" है।
आठ ऐसे कॉल (8 सेंट-रजिस्टरों) के बाद, प्रोसेसर एक ध्वज सेट करता है जो स्टैक भरा हुआ है, और कुछ सामान्य फ्लोटिंग-पॉइंट ऑपरेशन NaN को परिणाम के रूप में वापस करना शुरू करते हैं। यह, बदले में, किसी भी चीज़ की ओर जाता है। इस बिंदु तक कि एक डायनासोर आपकी पीठ के पीछे चल सकता है।

नैतिक : प्रलेखन को ध्यान से पढ़ें। यदि कोई चीज़ दस्तावेज़ीकरण के विपरीत काम करती है, तो वास्तव में यह नहीं पता है कि यह बड़ी समस्याओं का कारण नहीं होगा।

NSLog

"हे, हे, तो NSLog के साथ क्या हो रहा है?" NSLog "इस समस्या का इलाज" क्यों करता है?
NSLog फ्लोटिंग पॉइंट ऑपरेशंस का उपयोग करता है। इसके अलावा, प्रहार विधि का उपयोग करते हुए, यह पाया गया कि इसके संचालन के लिए FPU स्टैक में दो रजिस्टरों की आवश्यकता होती है। और FPU स्टैक, यदि पूरी तरह से आबादी है, तो उचित ओवरफ्लो ध्वज सेट करता है। और एक ऑपरेशन में जो स्टैक से मान निकालता है, स्टैक रजिस्टरों में से एक को "उपयोग करने के लिए स्वतंत्र" के रूप में चिह्नित करता है।

 // Tag word (state of st0 - st7 registers) // 00 - Used // 10 - Invalid // 11 - Unused // before NSLog st0 st1 st2 st3 st4 st5 st6 st7 10 00 00 00 00 00 00 00 // After NSLog st0 st1 st2 st3 st4 st5 st6 st7 11 11 00 00 00 00 00 00

इस तरह, अमान्य राज्य रजिस्टर st0 से गायब हो जाता है , इस वजह से, जब उससे मूल्य लेने की कोशिश की जाती है, तो कोई भी NaN प्राप्त नहीं करता है, और इसे UITextView के पैरामीटर के रूप में आगे नहीं देता है।

तो, NSLog समस्या का इलाज नहीं करता है। वह उसे थोड़ी देर तक जीवित रहने देता है, जब तक कि आवेदन की मृत्यु नहीं हो जाती, तब तक कोडन "अचानक"।

यहाँ इस तरह के एक "जादू है।" अब आप अपने रिज्यूमे में सुरक्षित रूप से एक पंक्ति लिख सकते हैं

मैं क्रैश और NSLogs का इलाज कर रहा हूं। सस्ती। कई वर्षों का अनुभव। 100% गारंटी।

मुझे उम्मीद है कि यह न केवल दिलचस्प था, बल्कि कुछ स्थानों पर भी - जानकारीपूर्ण।

PS फिर से मेरी मदद करने और विचारों की धारा सुनने के लिए डार्कप्रॉगर और विक्सेंटेल को धन्यवाद।

एक क्रैश और NSLog की कहानी जिसने उसका इलाज किया