अपवाद कोड का अर्थ क्या है EXC_I386_GPFLT?
क्या इसका अर्थ स्थिति के अनुसार भिन्न होता है?
उस स्थिति में, मैं EXC_BAD_ACCESSअपवाद कोड के साथ अपवाद प्रकार का उल्लेख कर रहा हूंEXC_I386_GPFLT
कार्यक्रम Xcode 5.0.1 में विकसित किया गया है, cblas_zgemm()BLAS लाइब्रेरी से निपट रहा है। (खैर, मुझे लगता है कि इससे कोई फर्क नहीं पड़ता ...)
आपका बहुत बहुत धन्यवाद!
जवाबों:
EXC_I386_GPFLT निश्चित रूप से "सामान्य सुरक्षा दोष" का उल्लेख कर रहा है, जो आपको बताने के लिए x86 का तरीका है कि "आपने कुछ ऐसा किया जो आपको करने की अनुमति नहीं है"। इसका आम तौर पर यह मतलब नहीं है कि आप मेमोरी सीमा से बाहर पहुंच जाते हैं, लेकिन यह हो सकता है कि आपका कोड सीमा से बाहर हो जाए और खराब कोड / डेटा का उपयोग इस तरह से किया जाए जो किसी प्रकार के सुरक्षा उल्लंघन का कारण बनता है।
दुर्भाग्य से यह पता लगाना मुश्किल हो सकता है कि समस्या अधिक संदर्भ के बिना वास्तव में क्या है, मेरे AMD64 प्रोग्रामर मैनुअल, 2005 से वॉल्यूम 2 में सूचीबद्ध 27 अलग-अलग कारण हैं - सभी खातों द्वारा, यह संभावना है कि 8 साल बाद कुछ जोड़ा जाएगा अधिक।
यदि यह 64-बिट सिस्टम है, तो एक प्रशंसनीय परिदृश्य यह है कि आपका कोड "गैर-विहित सूचक" का उपयोग कर रहा है - जिसका अर्थ है कि 64-बिट पता इस तरह से बनता है कि पते के ऊपरी 16 बिट्स नहीं होते हैं निचले 48 बिट्स के शीर्ष की सभी प्रतियां (दूसरे शब्दों में, एक पते के शीर्ष 16 बिट्स सभी 0 या सभी 1 होने चाहिए, 16 बिट्स के नीचे बिट के आधार पर)। यह नियम यह गारंटी देने के लिए है कि वास्तुकला "पता सीमा में मान्य बिट्स की संख्या का सुरक्षित रूप से विस्तार कर सकता है"। यह इंगित करेगा कि कोड या तो कुछ पॉइंटर डेटा को अन्य सामान के साथ अधिलेखित कर रहा है, या कुछ पॉइंटर मान को पढ़ते समय सीमा से बाहर जा रहा है।
एक अन्य संभावित कारण एक एसएसई रजिस्टर के साथ अनइंस्टॉल एक्सेस है - दूसरे शब्द में, 16-बाइट एसएसई रजिस्टर को एक पते से पढ़ना जो 16-बाइट गठबंधन नहीं है।
जैसा कि मैंने कहा, कई अन्य संभावित कारण हैं, लेकिन उनमें से अधिकांश में ऐसी चीजें शामिल हैं जो "सामान्य" कोड 32- या 64-बिट ओएस में नहीं करेंगे (जैसे कि अवैध चयनकर्ता सूचकांक के साथ लोडिंग सेगमेंट रजिस्टर करना या लिखना MSR (मॉडल विशिष्ट रजिस्टर))।
स्रोत को डिबग और खोजने के लिए: एप्लिकेशन के लिए लाश सक्षम करें (उत्पाद \ योजना) और लॉन्च उपकरण, लाश का चयन करें। अपने ऐप को Xcode में चलाएं फिर इंस्ट्रूमेंट्स स्टार्ट रिकॉर्डिंग पर जाएं। अपने ऐप पर वापस जाएं और त्रुटि उत्पन्न करने का प्रयास करें। यदि कोई एक है तो इंस्ट्रूमेंट को खराब कॉल (ज़ोंबी के लिए) का पता लगाना चाहिए।
आशा करता हूँ की ये काम करेगा!
आप अक्सर हेडर फ़ाइलों से जानकारी प्राप्त कर सकते हैं। उदाहरण के लिए:
$ cd /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
$ find usr -name \*.h -exec fgrep -l EXC_I386_GPFLT {} \;
usr/include/mach/i386/exception.h
^C
$ more usr/include/mach/i386/exception.h
....
#define EXC_I386_GPFLT 13 /* general protection fault */ठीक है, इसलिए यह एक सामान्य सुरक्षा दोष है (जैसा कि इसके नाम से पता चलता है)। Googling "i386 सामान्य सुरक्षा दोष" कई हिट देता है, लेकिन यह दिलचस्प लगता है:
सेगमेंट डिस्क्रिप्टर का उपयोग करके मेमोरी प्रोटेक्शन भी लागू किया जाता है। सबसे पहले, प्रोसेसर यह जांचता है कि क्या किसी खंड में लोड किया गया मान वैध विवरणक का संदर्भ देता है। फिर यह जांचता है कि गणना की गई प्रत्येक रैखिक पता वास्तव में खंड के भीतर है। इसके अलावा, सेगमेंट डिस्क्रिप्टर में जानकारी के खिलाफ एक्सेस (पढ़ने, लिखने या निष्पादित) का प्रकार जांचा जाता है। जब भी इनमें से एक चेक विफल होता है, तो अपवाद (व्यवधान) 13 (हेक्स 0 डी) उठाया जाता है। इस अपवाद को सामान्य सुरक्षा दोष (GPF) कहा जाता है।
यह 13हेडर फ़ाइलों में जो हमने देखा, उससे मेल खाता है, इसलिए यह एक ही चीज की तरह दिखता है। हालांकि एप्लिकेशन प्रोग्रामर के दृष्टिकोण से, इसका मतलब है कि हम स्मृति का उल्लेख कर रहे हैं जो हमें नहीं होना चाहिए, और यह वास्तव में कोई फर्क नहीं पड़ता कि यह हार्डवेयर पर कैसे लागू किया जाता है।
मैंने सोचा कि यह मेरी इकाई परीक्षणों के दौरान क्यों दिखाई दिया।
मैंने एक प्रोटोकॉल में एक विधि घोषणा को जोड़ा है जिसमें शामिल है throws ; लेकिन संभावित फेंकने की विधि का उस विशेष परीक्षण में भी उपयोग नहीं किया गया था। टेस्ट में लाश को सक्षम करना बहुत अधिक परेशानी की तरह लग रहा था।
एक didK साफ किया चाल बदल गया। जब मैं वास्तविक समस्याओं को हल करता हूं, तो मैं हमेशा फ्लैगबर्गहेड हूं।
मैंने स्विफ्ट 4.2 पर एक समान अपवाद दिया था। मैंने अपने कोड में बग ढूंढने की कोशिश में लगभग आधे घंटे का समय बिताया, लेकिन Xcode को बंद करने और व्युत्पन्न डेटा फ़ोल्डर को हटाने के बाद यह समस्या आ गई है। यहाँ शॉर्टकट है:
rm -rf ~/Library/Developer/Xcode/DerivedDataमेरे मामले में iOS सिम्युलेटर पर एक ऐप चलाने पर Xcode में त्रुटि आई थी। हालांकि मैं विशिष्ट प्रश्न का उत्तर नहीं दे सकता "त्रुटि का अर्थ क्या है", मैं कह सकता हूं कि मुझे क्या मदद मिली, शायद यह दूसरों की भी मदद करता है।
मेरे लिए समाधान Erase All Content and Settingsसिम्युलेटर में और Clean Build Folder...Xcode में था।
एक दृश्य छोड़ते समय मेरे पास यह मुद्दा था (पिछले दृश्य में वापस पॉप)।
कारण था
addSubview(view)
view.translatesAutoresizingMaskIntoConstraints = false
NSLayoutConstraint.activate([
view.leadingAnchor.constraint(equalTo: safeAreaLayoutGuide.leadingAnchor),
view.topAnchor.constraint(equalTo: safeAreaLayoutGuide.topAnchor),
view.trailingAnchor.constraint(equalTo: safeAreaLayoutGuide.trailingAnchor),
view.bottomAnchor.constraint(equalTo: safeAreaLayoutGuide.bottomAnchor)
])बदलें safeAreaLayoutGuideकरने के लिएselfसमस्या हल लिए ।
मतलब सुरक्षित क्षेत्र के बजाय पर्यवेक्षक के अग्रणी, अनुगामी, ऊपर, नीचे के साथ दृश्य संरेखित करता है)
यह मेरे साथ हुआ क्योंकि दो अलग-अलग वर्गों में एक ही चर नाम का उपयोग करते हुए Xcode मुझे पसंद नहीं आया (जो एक ही प्रोटोकॉल के अनुरूप है, अगर यह मायने रखता है, हालांकि चर नाम का किसी भी प्रोटोकॉल से संबंधित कुछ भी नहीं है)। मैंने बस अपने नए चर का नाम बदल दिया।
डिबगिंग करते समय मुझे इसे देखने के लिए बसने वालों में कदम रखना पड़ा। यह उत्तर iOS पर लागू होता है
यदि त्रुटि को एक क्लोजर के अंदर फेंक दिया जाता है जो कि परिभाषित selfकरता है unowned, तो आप सीमित हो सकते हैं कि आप क्या एक्सेस कर सकते हैं और कुछ स्थितियों में इस त्रुटि कोड को प्राप्त करेंगे। खासतौर पर डेब्यू करते समय। यदि आपके लिए यह मामला बदलने की कोशिश [unowned self]करता है[weak self]
मुझे यह करते हुए यह त्रुटि मिली:
NSMutableDictionary *aDictionary=[[NSMutableDictionary alloc] initWithObjectsAndKeys:<#(nonnull id), ...#>, nil]; //with 17 objects and keysजब मैं वापस लौटा तो यह चला गया:
NSMutableDictionary *aDictionary=[[NSMutableDictionary alloc] init];
[aDictionary setObject:object1 forKey:@"Key1"]; //17 timesमेरे लिए यह स्टोरीबोर्ड से संबंधित मुद्दा है सेट आईओएस 9.0 और बाद में पहले आईओएस 10.0 और बाद के सेट के लिए व्यूकंट्रोलर बिल्ड का विकल्प है। वास्तव में मैं 10 से आईओएस 9.3 तक इस क्रिया को डाउनग्रेड करना चाहता हूं।