2012-04-01 12 views
6

मेरे पास एक्सकोड 4.3.1, आईओएस 5.1 है, और मेरे ऐप के निर्माण के लिए ARC चालू है।ऐप डीबग बिल्ड के साथ ठीक चलाता है, लेकिन रिलीज बिल्ड पर क्रैश, संभावित कारण क्या हो सकते हैं?

अब ऐप डीबग बिल्ड में ठीक चलाता है, लेकिन रिलीज बिल्ड पर क्रैश होता है। अंतर के लिए संभावित कारण क्या हो सकता है? मैं संसाधन प्रबंधन के लिए पूरी तरह से ARC पर भरोसा करता हूं। मैंने क्रैश लॉग को देखा, यह संकेत दे रहा है कि संदर्भित स्मृति पहले ही रिलीज़ हुई थी। ARC का उपयोग करते समय, सामान्य नुकसान क्या हो सकता है जो खुदरा निर्माण पर समस्या का कारण बन सकता है?

निम्नलिखित मैं क्या क्रैश लॉग से मिला

Exception Type: EXC_BAD_ACCESS (SIGSEGV) 
Exception Codes: KERN_INVALID_ADDRESS at 0x6f636552 
Crashed Thread: 0 

संपादित

एप्लिकेशन की तैनाती लक्ष्य iOS 5.0 है। मैं इंटरनेट कनेक्शन का उपयोग करता हूं, वर्तमान क्रैश उस समय होता है जब UITableViewController पर दिखाने के लिए वेब सेवा से लौटाया गया डेटा "प्रतिपादन" होता है। पूरा ऐप ARC का उपयोग कर रहा है, तीसरे पक्ष की कुछ स्रोत फ़ाइलों को छोड़कर जिसके लिए मेरे पास ARC बंद है।

+0

Pls अधिक संकेत देते हैं, परिनियोजन लक्ष्य? क्या आप इंटरनेट से कनेक्शन का उपयोग कर रहे हैं? आपकी सभी कक्षाएं एआरसी या उनमें से कुछ का उपयोग करती हैं? – Andrea

+0

किया गया, कृपया – tom

+0

से ऊपर अपडेट देखें मुझे लगता है कि सिम पर ज़ोंबी उपकरणों का उपयोग करके अपने ऐप का परीक्षण करना बेहतर है। तथ्य यह है कि आप एआरसी और गैर-एआरसी कक्षाओं को मिश्रित कर रहे हैं, प्रतिनिधिमंडल या अधिसूचना पैटर्न का उपयोग करके कुछ समस्या पैदा कर सकते हैं। यह समझना मुश्किल है कि डिवाइस पर क्यों हो रहा है, सिम पर नहीं, लेकिन शायद दोनों के बीच हार्डवेयर अंतर के कारण है। – Andrea

उत्तर

0

मैं इस सवाल का जवाब नहीं हो सकता है, लेकिन मैं कुछ hunches सूची आप की कोशिश करने के लिए जा रहा हूँ:

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

यदि मैं और अधिक सोच सकता हूं, तो मैं उन्हें जोड़ने की कोशिश करूंगा।

4

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

@property (weak) UILabel * label; 
... 
self.label = [[UILabel alloc] init]; 
[self.view addSubview:self.label]; 
... 
self.label.text = @"hello"; 

के लिए मैं इस कारण रिलीज पर बुरा पहुँच दुर्घटनाओं बनाता देखा और डिबग पर किसी का ध्यान नहीं गया है।

+0

हां, यह निश्चित रूप से एक दुर्घटना का कारण बन सकता है और एक गलती है। आपको कभी कमजोर रेफरी नहीं होना चाहिए। –

0

क्या आपके पास रिलीज और डीबग के लिए एक अलग लक्ष्य है? जांचें कि सभी फ़ाइलों को रिलीज लक्ष्य के लिए सही तरीके से संदर्भित किया गया है या नहीं।

हमारे मामले में, रिलीज लक्ष्य द्वारा UIButton पर एक श्रेणी नहीं देखी गई थी। जब तक किसी ने उस श्रेणी द्वारा लागू विधि लागू नहीं की, तब तक एक विज्ञापन-निर्माण का निर्माण ठीक हो गया। चूंकि हमने एड-होक बिल्ड से संग्रह संग्रहित नहीं किया है, इसलिए क्रैश को डीबग करने का कोई तरीका नहीं था।(सबक सीखा)

यह सुनिश्चित नहीं है कि इसे क्रैश लॉग में EXC_BAD_ACCESS के रूप में सूचीबद्ध किया गया है, लेकिन किसी को उनकी रिलीज-विशिष्ट क्रैश की पहचान करने में मदद कर सकता है।

संबंधित मुद्दे