EXC_BAD_ACCESS सिग्नल प्राप्त हुआ

Question

डिवाइस पर एप्लिकेशन को तैनात करते समय, प्रोग्राम निम्न त्रुटि के साथ कुछ चक्रों के बाद छोड़ देगा:

Program received signal: "EXC_BAD_ACCESS".

कार्यक्रम iPhone सिम्युलेटर पर किसी भी मुद्दे के बिना चलता है, यह डिबग भी करेगा और जब तक मैं एक बार में निर्देशों के माध्यम से कदम बढ़ाता हूं। जैसे ही मैंने इसे फिर से चलने दिया, मैं EXC_BAD_ACCESSसिग्नल मारूंगा।

इस विशेष मामले में, यह एक्सेलेरोमीटर कोड में एक त्रुटि थी। यह सिम्युलेटर के भीतर निष्पादित नहीं होगा, यही वजह है कि इसने कोई त्रुटि नहीं डाली। हालाँकि, यह एक बार डिवाइस पर लागू हो जाएगा।

इस प्रश्न के अधिकांश उत्तर सामान्य EXC_BAD_ACCESSत्रुटि से निपटते हैं , इसलिए मैं इस ओपन को एक खूंखार बैड एक्सेस त्रुटि के लिए एक पकड़ के रूप में छोड़ दूंगा।

EXC_BAD_ACCESSआम तौर पर एक अवैध मेमोरी एक्सेस के परिणामस्वरूप फेंका जाता है। आप नीचे दिए गए उत्तरों में अधिक जानकारी पा सकते हैं।

क्या आपने EXC_BAD_ACCESSपहले संकेत का सामना किया है, और आपने इसके साथ कैसे व्यवहार किया?

Answer 1

आपके विवरण से मुझे सबसे अधिक संभावना स्पष्टीकरण पर संदेह है कि आपके स्मृति प्रबंधन में कुछ त्रुटि है। आपने कहा कि आप कुछ हफ्तों के लिए iPhone के विकास पर काम कर रहे हैं, लेकिन यह नहीं कि आप सामान्य रूप से Objective C के साथ अनुभव कर रहे हैं। यदि आप किसी अन्य पृष्ठभूमि से आए हैं, तो आपको स्मृति प्रबंधन नियमों को वास्तव में आंतरिक करने से पहले थोड़ा समय लग सकता है - जब तक कि आप इसका एक बड़ा बिंदु नहीं बनाते हैं।

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

लेकिन अगर आप के बारे में कुछ और से कुछ वापस पाने सहित कारखाना तरीकों (जैसे [NSString stringWithFormat]तो यह महत्वपूर्ण है कि आप की जरूरत है कि -) तो आप एक autorelease संदर्भ है, जो साधन यह अन्य कोड से भविष्य में किसी समय में जारी किया जा सकता है होगा इसे तत्काल कार्य से परे रखने के लिए जिसे आप इसे बनाए रखते हैं। यदि आप नहीं करते हैं, तो आपके द्वारा उपयोग किए जाने के दौरान मेमोरी आवंटित की जा सकती है, या आपके एमुलेटर परीक्षण के दौरान संयोग से वैध है, लेकिन जारी होने की संभावना है, लेकिन डिवाइस पर चलने पर खराब एक्सेस त्रुटियों के रूप में रिलीज़ होने और खराब होने की संभावना है।

इन चीजों को ट्रैक करने का सबसे अच्छा तरीका है, और वैसे भी एक अच्छा विचार है (भले ही कोई स्पष्ट समस्याएं न हों) उपकरण टूल में एप्लिकेशन को चलाने के लिए है, विशेष रूप से लीक विकल्प के साथ।

Comments

मेरे पास कुछ एक्सेलेरोमीटर सैंपलिंग कोड थे जो मेरे ऐप के लिए महत्वपूर्ण नहीं थे, जो हटाने के बाद, खराब एक्सेस एरर को खत्म कर दिया। जिससे समझ में आता है कि सिम्युलेटर में एक्सीलेरोमीटर नहीं है। मुझे यह अजीब लगता है कि यह कोड मौजूद था, इस त्रुटि को पैदा करने से पहले एक सप्ताह के लिए, अछूता ...

— हेक्टर रामोस

मैं ऑब्जेक्टिव-सी के लिए नया हूं इसलिए मेरी ज्यादातर समस्याएं स्मृति प्रबंधन से पैदा होनी चाहिए। सी ++ में कुछ वर्षों के बाद, मैं पिछले तीन या चार वर्षों से ज्यादातर जावा का उपयोग कर रहा हूं, इसलिए मैंने स्मृति प्रबंधन पर जंग लगा दी है। आपके उत्तर के लिए धन्यवाद!

— हेक्टर रामोस

कोई बात नहीं - खुशी है कि आपने इसे ठीक किया। स्मृति प्रबंधन वास्तव में कठिन नहीं है - शीर्ष पर लाने के लिए आपको बस यह सुनिश्चित करने की ज़रूरत है कि आप नियमों को सीखें और अच्छी आदतों में शामिल हों।

— फ़िस्क्लेयर किया गया

मैंने जो समस्या बनाई है, वह विशेष रूप से स्ट्रिंग्स (और ऐसे) जो मैं बनाता हूं, जारी करने में बहुत आक्रामक होने के साथ लगता है। मुझे अभी भी 100% यकीन नहीं है कि क्या जारी किया जाना चाहिए और कब, लेकिन फिल के जवाब ने निश्चित रूप से मदद की।

— pluckyglen

अगर मैंने सही तरीके से उसका पालन किया, तो cmculloh, हाँ यह सही काम था। आप ऑब्जेक्ट को ऑब्जेक्ट से नहीं लौटाते हैं।

— philsquared

Answer 2

EXC_BAD_ACCESS का एक प्रमुख कारण जारी वस्तुओं तक पहुँचने की कोशिश करना है।

इसका निवारण कैसे करें, यह जानने के लिए, इस दस्तावेज़ को पढ़ें: DebuggingAutoReleasePool

यहां तक ​​कि अगर आपको नहीं लगता कि आप "ऑटो-रिलीज़ ऑब्जेक्ट जारी कर रहे हैं", तो यह आपके लिए लागू होगा।

यह विधि बहुत अच्छी तरह से काम करती है। मैं इसका हर समय बड़ी सफलता के साथ उपयोग करता हूँ !!

सारांश में, यह बताता है कि कोको के NSZombie डिबगिंग क्लास और कमांड लाइन "malloc_history" टूल का उपयोग कैसे किया जाए ताकि आपके कोड में जारी की गई ऑब्जेक्ट को ठीक से खोजा जा सके।

पक्षीय लेख:

रनिंग इंस्ट्रूमेंट्स और लीक के लिए जाँच EXC_BAD_ACCESS के समस्या निवारण में मदद नहीं करेगा। मुझे पूरा यकीन है कि मेमोरी लीक का EXC_BAD_ACCESS से कोई लेना-देना नहीं है। रिसाव की परिभाषा एक ऐसी वस्तु है जिसकी अब आपके पास पहुँच नहीं है, और इसलिए आप इसे कॉल नहीं कर सकते।

अद्यतन: मैं अब लेक्स डिबग करने के लिए इंस्ट्रूमेंट्स का उपयोग करता हूं। Xcode 4.2 से, Product-> प्रोफ़ाइल चुनें और जब इंस्ट्रूमेंट्स लॉन्च हों, तो "लाश" चुनें।

Comments

वह सिद्दत बहुत महत्वपूर्ण है। लीक EXC_BAD_ACCESS का कारण नहीं बन सकता (उन्हें अन्य समस्याएं हैं)। मैंने EXC_BAD_ACCESS loufranco.com/blog/files/Understanding-EXC_BAD_ACCESS.html

— लो फ्रेंको

Xcode में लाश उपकरण शानदार है! मैंने अपराधी को 3 मिनट में पाया, घंटों नहीं।

— अराम कोचरन

उत्तर में उपर्युक्त लिंक उपलब्ध नहीं है। 404 में त्रुटि नहीं मिली।

— तेजस

Answer 3

EXC_BAD_ACCESS सिग्नल एक अमान्य कॉल को सिस्टम कॉल में पास करने का परिणाम है। मुझे ओएस एक्स पर एक परीक्षण कार्यक्रम के साथ आज एक ही मिला है - मैं एक अनधिकृत चर पास कर रहा था pthread_join(), जो कि पहले के समय के कारण था।

मैं iPhone विकास से परिचित नहीं हूं, लेकिन आपको अपने सभी बफर पॉइंटर्स को दोबारा जांचना चाहिए जो आप सिस्टम कॉल पर भेज रहे हैं। अपने संकलक के चेतावनी स्तर को पूरे तरीके से क्रैक करें (जीसीसी के साथ, विकल्पों -Wallऔर -Wextraविकल्पों का उपयोग करें)। जितना संभव हो उतना सिम्युलेटर / डिबगर पर कई निदान सक्षम करें।

Answer 4

मेरे अनुभव में, यह आम तौर पर एक अवैध मेमोरी एक्सेस के कारण होता है। सुनिश्चित करने के लिए कि वे आरंभीकृत हैं, सभी पॉइंटर्स, विशेष रूप से ऑब्जेक्ट पॉइंटर्स की जाँच करें। सुनिश्चित करें कि यदि आप एक का उपयोग कर रहे हैं, तो अपने MainWindow.xib फ़ाइल को सभी आवश्यक कनेक्शनों के साथ ठीक से सेट करें।

यदि उस ऑन-पेपर चेकिंग में से कोई भी कुछ भी नहीं बदलता है, और यह एकल-स्टेपिंग के दौरान नहीं होता है, तो NSLog () कथनों के साथ त्रुटि का पता लगाने का प्रयास करें: अपने कोड को उनके साथ छिड़कें, उन्हें तब तक घुमाएँ जब तक कि आप उस पंक्ति को अलग न कर दें, जिससे वह उत्पन्न हो रही है त्रुटि। फिर उस लाइन पर एक ब्रेकपॉइंट सेट करें और अपना प्रोग्राम चलाएं। जब आप ब्रेकपॉइंट मारते हैं, तो सभी चर और उन में वस्तुओं की जांच करें, यह देखने के लिए कि क्या कुछ भी ऐसा नहीं लगता है जैसे आप उम्मीद करते हैं। मैं विशेष रूप से उन चर के लिए एक नज़र रखूंगा जिनकी वस्तु वर्ग ऐसी चीज़ है जिसकी आपको उम्मीद नहीं थी। यदि एक वैरिएबल में UIWindow होना चाहिए, लेकिन इसमें एक NSNotification है, तो समान अंतर्निहित त्रुटि तब अलग तरीके से प्रकट हो सकती है जब डिबगर चालू नहीं होता है।

Answer 5

मैंने अभी एक EXC_BAD_ACCESS पर नज़र रखने में कुछ घंटे बिताए और पाया NSZili और अन्य env var ने मुझे कुछ भी नहीं बताया।

मेरे लिए, यह प्रारूप विनिर्देशकों के साथ एक बेवकूफ NSLog बयान था, लेकिन कोई आर्गन पारित नहीं हुआ।

NSLog(@"Some silly log message %@-%@");

द्वारा तय किया गया

NSLog(@"Some silly log message %@-%@", someObj1, someObj2);

Answer 6

2010 के WWDC वीडियो ऐप्पल डेवलपर प्रोग्राम में किसी भी प्रतिभागी के लिए उपलब्ध हैं। एक शानदार वीडियो है: "सत्र 311 - इंस्ट्रूमेंट के साथ एडवांस्ड मेमोरी एनालिसिस" जो उपकरणों में लाश का उपयोग करने और अन्य मेमोरी समस्याओं को डीबग करने के कुछ उदाहरण दिखाता है।

लॉगिन पेज के लिंक के लिए यहां क्लिक करें ।

Answer 7

पूर्ण उत्तर नहीं है, लेकिन एक विशिष्ट स्थिति जहां मुझे यह मिला है, जब किसी ऑब्जेक्ट को एक्सेस करने की कोशिश कर रहा है कि 'मर गया' क्योंकि मैंने ऑटोरिलिज़ का उपयोग करने की कोशिश की:

netObjectDefinedInMyHeader = [[[MyNetObject alloc] init] autorelease];

इसलिए, उदाहरण के लिए, मैं वास्तव में इसे 'सूचित' करने के लिए एक ऑब्जेक्ट के रूप में पारित कर रहा था (इसे एक श्रोता, पर्यवेक्षक के रूप में पंजीकृत किया गया था, जो भी मुहावरे आपको पसंद है) लेकिन अधिसूचना भेजे जाने के बाद यह पहले ही मर गया था और मुझे EXC_BAD_ACCESS मिलेगा। इसे बदलने [[MyNetObject alloc] init]और बाद में इसे जारी करने के लिए उपयुक्त के रूप में त्रुटि को हल किया।

ऐसा होने का एक और कारण उदाहरण के लिए है यदि आप किसी ऑब्जेक्ट में पास होते हैं और इसे स्टोर करने का प्रयास करते हैं:

myObjectDefinedInHeader = aParameterObjectPassedIn;

बाद में जब myObjectDefinedInHeader को एक्सेस करने की कोशिश की जाती है तो आप मुश्किल में पड़ सकते हैं। का उपयोग करते हुए:

myObjectDefinedInHeader = [aParameterObjectPassedIn retain];

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

Answer 8

बस एक और स्थिति जोड़ने के लिए जहां यह हो सकता है:

मेरे पास कोड था:

NSMutableString *string;
[string   appendWithFormat:@"foo"];

जाहिर है मैं स्ट्रिंग के लिए मेमोरी आवंटित करना भूल गया था:

NSMutableString *string = [[NSMutableString alloc] init];
[string   appendWithFormat:@"foo"];

समस्या को ठीक करता है।

Comments

यह मेरे लिए किसी भी त्रुटि का कारण नहीं बनता है क्योंकि स्ट्रिंग को एनआईएल के लिए आरंभीकृत किया जाता है और शून्य ऑब्जेक्ट पैटर्न का उपयोग करके शून्य पर एक विधि को कॉल करना कुछ भी नहीं करता है।

— लियोन याहदव

Answer 9

EXC_BAD_ACCESS अपवादों को पकड़ने से पहले एक और तरीका है , XCode 4+ में स्थिर विश्लेषक ।

उत्पाद> विश्लेषण (शिफ्ट + cmd + B) के साथ स्थिर विश्लेषक चलाएँ। विश्लेषक द्वारा उत्पन्न किसी भी संदेश पर क्लिक करने से आपके स्रोत पर एक आरेख ओवरले हो जाएगा जिसमें आपत्तिजनक वस्तु के अनुरक्षण / रिलीज का अनुक्रम दिखाई देगा।

Answer 10

मुझे objc_exception_throw पर एक ब्रेकपॉइंट सेट करना उपयोगी लगता है। जब आप EXC_BAD_ACCESS प्राप्त करते हैं, तो डिबगर को तोड़ देना चाहिए।

निर्देश यहाँ मिल सकते हैं DebuggingTechniques

Answer 11

"यदि आपने इसे आवंटित नहीं किया है या इसे बनाए नहीं रखते हैं, तो इसे जारी न करें" के सरल नियम का उपयोग करें।

Comments

उस नियम को "... कॉपी करें ..." द्वारा विस्तारित करें और आपको ठीक होना चाहिए।

— तक

Answer 12

EXC_BAD_ACCESS को कैसे डिबग करें

ऊपर दिए गए लिंक की जाँच करें और जैसा कि यह कहता है .... एनएसज़ीन का उपयोग करने के लिए बस कुछ त्वरित निर्देश

एप्लिकेशन चलाएँ और उसके बाद विफल ("EXC_BAD_ACCESS" के बजाय "बाधित" प्रदर्शित होना चाहिए ... कंसोल (रन> कंसोल) की जांच करें ... वहां एक संदेश होना चाहिए जो अब बता रहा है कि वह किस ऑब्जेक्ट को एक्सेस करने की कोशिश कर रहा था।

बेन

Answer 13

मैं पिछले चार घंटों से इस त्रुटि को हल करने के लिए डिबगिंग और रीफैक्टरिंग कोड बना रहा हूं। ऊपर एक पोस्ट ने मुझे समस्या देखने के लिए प्रेरित किया:

प्रॉपर्टी से पहले: startPoint = [[डेटाप्वाइंट आबंटित] init]; startPoint = [DataPointList objectAtIndex: 0];
। । । x = startPoint.x - 10; // EXC_BAD_ACCESS

प्रॉपर्टी के बाद: startPoint = [[डाटाप्वाइंट आबंटित] init]; startPoint = [[डेटाप्लांटलिस्ट ऑब्जेक्टअंडेक्स: 0] बनाए रखें];

अलविदा EXC_BAD_ACCESS

Comments

मैंने भी ऐसी ही गलती की। मैं उस उदाहरण को पढ़ना भूल गया जिसके कारण दुर्घटना हुई थी और मुझे यह पता लगाने में घंटों लग गए। आपके अनुभव ने मुझे मेरा पता लगाने के लिए जलाया। धन्यवाद!

— डेविड.छू.का।

Answer 14

जब आप कर रहे हैं आशा है कि आप 'स्ट्रिंग' जारी कर रहे हैं!

Answer 15

मैं एक init-Method में स्व वापस जाना भूल गया ...;)

Comments

यह एक संकलित समय चेतावनी / त्रुटि होना चाहिए और रनटाइम के दौरान EXC_BAD_ACCESS नहीं होना चाहिए।

— 9

Answer 16

यह एक उत्कृष्ट धागा है। यहां मेरा अनुभव है: मैंने संपत्ति की घोषणा पर कीवर्ड को बनाए रखा / असाइन किया। मैंने कहा:

@property (nonatomic, assign) IBOutlet UISegmentedControl *choicesControl;
@property (nonatomic, assign) IBOutlet UISwitch *africaSwitch;
@property (nonatomic, assign) IBOutlet UISwitch *asiaSwitch;

जहां मुझे कहना चाहिए था

@property (nonatomic, retain) IBOutlet UISegmentedControl *choicesControl;
@property (nonatomic, retain) IBOutlet UISwitch *africaSwitch;
@property (nonatomic, retain) IBOutlet UISwitch *asiaSwitch;

Comments

अजीब बात है, आपको IBOutlet को बनाए रखने की आवश्यकता क्यों होगी? उनका प्रबंधन आपके लिए स्वचालित रूप से किया जाता है।

— jv42

Answer 17

मुझे iPhone पर EXC_BAD_ACCESS का सामना करना पड़ा, जबकि एक सी विधि को निष्पादित करने की कोशिश कर रहा था जिसमें एक बड़ा सरणी शामिल था। सिम्युलेटर मुझे कोड चलाने के लिए पर्याप्त मेमोरी देने में सक्षम था, लेकिन डिवाइस नहीं (सरणी एक लाख वर्ण था, इसलिए यह एक अत्यधिक अतिवाद था!)।

EXC_BAD_ACCESS विधि के प्रवेश बिंदु के ठीक बाद हुआ, और मुझे काफी समय से भ्रम हो गया था क्योंकि यह सरणी घोषणा के पास कहीं नहीं था।

शायद किसी और को मेरे दो घंटे के बाल खींचने से फायदा हो।

Answer 18

एक गैर-आबंटित पॉइंटर को बाहर निकालना भूल गया dealloc। मुझे UINavigationController के अपने मूल दृश्य पर exc_bad_access मिल रहा था, लेकिन कभी-कभी ही। मुझे लगता है कि समस्या rootView में थी क्योंकि यह अपने दृश्य के माध्यम से आधे रास्ते में दुर्घटनाग्रस्त हो गया था {}। यह खराब डीललोक {} रिलीज़ के साथ दृश्य को पॉप करने के बाद ही हुआ, और यह वही था!

"EXC_BAD_ACCESS" [330 प्रोसेस करने के लिए स्विच करना] अब प्रोग्राम के लिए कोई मेमोरी उपलब्ध नहीं है: मॉलको कॉल करने के लिए असुरक्षित

मुझे लगा कि यह एक समस्या है जहाँ मैं आवंटित करने की कोशिश कर रहा था ... न कि जहाँ मैं एक गैर-आवंटन जारी करने की कोशिश कर रहा था, डी'ओह!

Answer 19

मैं EXC_BAD_ACCESS से कैसे निपटता हूं

कभी-कभी मुझे लगता है कि जब EXC_BAD_ACCESS त्रुटि होती है, तो Xcode main.m वर्ग में त्रुटि दिखाएगा, जहां दुर्घटना होती है (कभी-कभी) कोई अतिरिक्त जानकारी नहीं देता है।

उन समय में हम Xcode में एक असाधारण ब्रेकपॉइंट सेट कर सकते हैं ताकि जब अपवाद पकड़ा जाए तो एक ब्रेकपॉइंट रखा जाएगा और उस लाइन में क्रैश हुए उपयोगकर्ता को सीधे सूचित कर सकेगा

Answer 20

NSAssert () कॉल विधि मान्य करने के लिए पैरामीटर नीचे ट्रैक करने और निल्स से गुजरने से बचने के लिए बहुत आसान है।

Answer 21

मुझे बस यही समस्या थी। मेरे लिए कारण एक कोरडैटा प्रबंधित ऑब्जेक्ट एन्स को हटाने के बाद इसे दूसरी जगह से पढ़ने की कोशिश कर रहा था।

Answer 22

मैं पिछले चार घंटों से इस त्रुटि को हल करने के लिए डिबगिंग और रीफैक्टरिंग कोड बना रहा हूं। ऊपर एक पोस्ट ने मुझे समस्या देखने के लिए प्रेरित किया:

इससे पहले की संपत्ति:

startPoint = [[DataPoint alloc] init] ;
startPoint= [DataPointList objectAtIndex: 0];
x = startPoint.x - 10; // EXC_BAD_ACCESS

इसके बाद की संपत्ति:

startPoint = [[DataPoint alloc] init] ;
startPoint = [[DataPointList objectAtIndex: 0] retain];

अलविदा EXC_BAD_ACCESS

अपने जवाब के लिए आपको बहुत बहुत धन्यवाद। मैं पूरे दिन इस समस्या से जूझता रहा। तुम कमाल हो!

Comments

क्या आप केवल तुरंत शुरू करने की ओवरराइटिंग नहीं कर रहे हैं? मुझे नहीं लगता कि आपको उस पहली पंक्ति की आवश्यकता है।

— टोक्साक

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

— ड्रीमलैक्स

Answer 23

बस जोड़ना है

Lynda.com में एक शानदार डीवीडी है, जिसे कहा जाता है

iPhone एसडीके आवश्यक प्रशिक्षण

और अध्याय 6, पाठ 3 सब के बारे में है EXEC_BAD_ACCESS और लाश के साथ काम ।

मेरे लिए यह समझना बहुत अच्छा था, न केवल त्रुटि कोड लेकिन मैं जारी किए गए ऑब्जेक्ट पर अधिक जानकारी प्राप्त करने के लिए लाश का उपयोग कैसे कर सकता हूं।

Answer 24

जाँच करने के लिए कि त्रुटि क्या हो सकती है

NSZombieEnabled का उपयोग करें।

अपने आवेदन में NSZombieEnabled सुविधा को सक्रिय करने के लिए:

प्रोजेक्ट चुनें> निष्पादन योग्य जानकारी विंडो खोलने के लिए सक्रिय निष्पादन योग्य संपादन करें। तर्क पर क्लिक करें। "पर्यावरण में सेट किए जाने वाले चर" अनुभाग में ऐड (+) बटन पर क्लिक करें। नाम कॉलम में NSZombieEnabled दर्ज करें और मान स्तंभ में YES। सुनिश्चित करें कि NSZombieEnabled प्रविष्टि के लिए चेकमार्क चयनित है।

मुझे यह जवाब iPhoneSDK पर मिला

Answer 25

मुझे पता है कि यह कुछ समय पहले पूछा गया था, लेकिन इस धागे को पढ़ने के बाद, मुझे XCode 4.2 के लिए समाधान मिला: उत्पाद -> योजना संपादित करें -> निदान टैब -> ज़ोंबी ऑब्जेक्ट सक्षम करें

एक अस्वीकृत वस्तु पर भेजे जा रहे संदेश को खोजने में मेरी मदद की।

Answer 26

जब आपके पास अनंत पुनरावृत्ति होती है, तो मुझे लगता है कि आपके पास भी यह त्रुटि हो सकती है। यह मेरे लिए एक मामला था।

Answer 27

यहां तक ​​कि एक अन्य संभावना: कतारों में ब्लॉकों का उपयोग करना, यह आसानी से हो सकता है कि आप किसी अन्य कतार में किसी ऑब्जेक्ट तक पहुंचने का प्रयास करें, जो इस समय पहले ही आबंटित हो चुका है। आमतौर पर जब आप GUI में कुछ भेजने की कोशिश करते हैं। यदि आपका अपवाद ब्रेकपॉइंट एक अजीब जगह पर सेट किया जा रहा है, तो यह कारण हो सकता है।

Answer 28

मुझे यह मिल गया क्योंकि मैं उपयोग नहीं कर रहा था [self performSegueWithIdentifier:sender:]और -(void) prepareForSegue:(UIstoryboardSegue *)सही था

Answer 29

@तार बनाते समय प्रतीक को मत भूलना , C-stringsजैसा NSStringsकि कारण होगा EXC_BAD_ACCESS।

इसे इस्तेमाल करो:

@"Some String"

इसके बजाय:

"Some String"

पुनश्च - आमतौर पर जब arrayबहुत सारे अभिलेखों की सामग्री को पॉप्युलेट किया जाता है ।

Answer 30

XCode 4 और इसके बाद के संस्करण, इसे इंस्ट्रूमेंट्स के साथ वास्तव में सरल बनाया गया है। बस लाश को उपकरण में चलाएं। यह ट्यूटोरियल इसे अच्छी तरह से समझाता है: exc_bad_access त्रुटि xcode उपकरणों को डीबग करना