2014-11-25 11 views
12

पर क्रैश, कई अन्य लोगों की तरह, एक्सकोड 6+ क्रैशिंग के साथ समस्याएं थीं। मुझे SourceKit क्रैश के साथ-साथ पूर्ण एप्लिकेशन क्रैश भी मिलते हैं। मुझे लगता है कि मैं 6.1.1 (डेवलपर सदस्य केंद्र) का प्रयास करूंगा और यह बदतर था, एक डीबगर ब्रेकपॉइंट अब एक पूर्ण अनुप्रयोग दुर्घटना में परिणाम देता है। तो मैंने कहा कि इसे भूल जाओ और 6.1 पर वापस चला गया, लेकिन डीबगर ब्रेकपॉइंट डालने पर मुझे अभी भी दुर्घटनाएं हुईं।एक्सकोड 6.1 और 6.1.1 डीबगर ब्रेकपॉइंट (सिम्युलेटर)

स्पष्ट रूप से ब्रेकपॉइंट के साथ यह क्रैश केवल सिम्युलेटर को प्रभावित करता है, भौतिक डिवाइस सेट करता है और बिना किसी समस्या के ब्रेकपॉइंट पर रुक जाता है। अजीब!

यह बिल्कुल गड़बड़ है !! किसी और को यह मिल रहा है?

बातें मैं कोशिश की है:

  • निकालें /Application/Xcode.app/ & ~/Library/डेवलपर/*
  • परियोजना
  • निष्पादन के लिए अपने लैपटॉप
  • ब्रेकप्वाइंट रिबूट की सफाई एक भौतिक डिवाइस पर (< < < < ====== यह काम करता है !!!)
  • एक चिकन और फैलाने की हत्या यह स्टैक ट्रेस के खून सभी
  • से अधिक

प्रमुख है:

Process:   Xcode [7904] 
Path:   /Applications/Xcode.app/Contents/MacOS/Xcode 
Identifier:  com.apple.dt.Xcode 
Version:   6.1 (6604) 
Build Info:  IDEFrameworks-6604000000000000~2 
App Item ID:  497799835 
App External ID: 752282650 
Code Type:  X86-64 (Native) 
Parent Process: launchd [185] 
Responsible:  Xcode [7904] 
User ID:   501 

Date/Time:  2014-11-25 12:32:49.348 -0800 
OS Version:  Mac OS X 10.9.5 (13F34) 
Report Version: 11 
Anonymous UUID: E22980F9-B80B-F985-200A-FE471C623C56 


Crashed Thread: 23 <DBGLLDBSessionThread (pid=7957)> 

Exception Type: EXC_BAD_ACCESS (SIGBUS) 
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000001409bdfd0 

VM Regions Near 0x1409bdfd0: 
    Stack     000000014093b000-00000001409bd000 [ 520K] rw-/rwx SM=COW thread 22 
--> STACK GUARD   00000001409bd000-00000001409be000 [ 4K] ---/rwx SM=NUL stack guard for thread 23 
    Stack     00000001409be000-0000000140a40000 [ 520K] rw-/rwx SM=COW thread 23 

Application Specific Information: 
ProductBuildVersion: 6A1052d 

...

Thread 23 Crashed:: <DBGLLDBSessionThread (pid=7957)> 
0 libsystem_pthread.dylib   0x00007fff90eb82cf __mtx_droplock + 17 
1 libsystem_pthread.dylib   0x00007fff90eb88f3 pthread_mutex_unlock + 60 
2 com.apple.LLDB.framework  0x000000011808f8be lldb_private::Mutex::Locker::~Locker() + 22 
3 com.apple.LLDB.framework  0x00000001180ed55f GDBRemoteCommunication::CheckForPacket(unsigned char const*, unsigned long, StringExtractorGDBRemote&) + 2423 
4 com.apple.LLDB.framework  0x00000001180ec99e GDBRemoteCommunication::WaitForPacketWithTimeoutMicroSecondsNoLock(StringExtractorGDBRemote&, unsigned int) + 88 
5 com.apple.LLDB.framework  0x00000001181eeb1b GDBRemoteCommunicationClient::SendPacketAndWaitForResponse(char const*, unsigned long, StringExtractorGDBRemote&, bool) + 91 
6 com.apple.LLDB.framework  0x00000001180f7574 ProcessGDBRemote::DoReadMemory(unsigned long long, void*, unsigned long, lldb_private::Error&) + 216 
7 com.apple.LLDB.framework  0x00000001181a452a lldb_private::Process::ReadMemoryFromInferior(unsigned long long, void*, unsigned long, lldb_private::Error&) + 94 
8 com.apple.LLDB.framework  0x0000000118171889 lldb_private::ProcessStructReader::ProcessStructReader(lldb_private::Process*, unsigned long long, lldb_private::ClangASTType) + 561 
9 com.apple.LLDB.framework  0x0000000118169082 lldb_private::SwiftLanguageRuntime::ClassMetadata::ClassMetadata(lldb_private::SwiftLanguageRuntime&, unsigned long long) + 354 
10 com.apple.LLDB.framework  0x000000011816625d lldb_private::SwiftLanguageRuntime::GetMetadataForLocation(unsigned long long) + 531 
11 com.apple.LLDB.framework  0x00000001181690d1 lldb_private::SwiftLanguageRuntime::ClassMetadata::ClassMetadata(lldb_private::SwiftLanguageRuntime&, unsigned long long) + 433 
12 com.apple.LLDB.framework  0x000000011816625d lldb_private::SwiftLanguageRuntime::GetMetadataForLocation(unsigned long long) + 531 
13 com.apple.LLDB.framework  0x00000001181690d1 lldb_private::SwiftLanguageRuntime::ClassMetadata::ClassMetadata(lldb_private::SwiftLanguageRuntime&, unsigned long long) + 433 
14 com.apple.LLDB.framework  0x000000011816625d lldb_private::SwiftLanguageRuntime::GetMetadataForLocation(unsigned long long) + 531 
15 com.apple.LLDB.framework  0x00000001181690d1 lldb_private::SwiftLanguageRuntime::ClassMetadata::ClassMetadata(lldb_private::SwiftLanguageRuntime&, unsigned long long) + 433 
16 com.apple.LLDB.framework  0x000000011816625d lldb_private::SwiftLanguageRuntime::GetMetadataForLocation(unsigned long long) + 531 
17 com.apple.LLDB.framework  0x00000001181690d1 lldb_private::SwiftLanguageRuntime::ClassMetadata::ClassMetadata(lldb_private::SwiftLanguageRuntime&, unsigned long long) + 433 
18 com.apple.LLDB.framework  0x000000011816625d lldb_private::SwiftLanguageRuntime::GetMetadataForLocation(unsigned long long) + 531 

...

+5

"एक चिकन की हत्या और प्रसार यह रक्त है सब कुछ खत्म हो" यह वास्तव में काम किया जाना चाहिए था। किस तरह का चिकन? – matt

+1

अधिक गंभीरता से, मेरा उत्तर यहाँ प्रयास करें: http://stackoverflow.com/a/6247073/341994 अंत में दो संपादन विशेष रूप से महत्वपूर्ण है। एक्सकोड कुछ बुराई कैश बनाए रखता है, जो भ्रष्ट/बासी हो सकता है, और उन्हें दूर उड़ाने से बहुत मदद मिल सकती है। – matt

+0

सुझावों के लिए धन्यवाद। मैंने सभी समाशोधन की कोशिश की, लेकिन समस्या अभी भी परिणाम है। मैंने अपने प्रश्न को अधिक जानकारी के साथ अपडेट किया और यह भी पता चला कि यह सिम्युलेटर पर ही होता है। भौतिक उपकरण डीबगर ब्रेकपॉइंट्स को क्रैश नहीं करता है। –

उत्तर

11

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

कृपया ध्यान दें हल करने में विफल रहा है कभी नहीं किया है: इन चरणों (क्रम में) सब करने के महत्वपूर्ण हो सकता है ... मुझे एहसास है कि उनमें से कुछ पहली नज़र में ओवरकिल की तरह लगते हैं या जैसे उन्हें कोई फर्क नहीं पड़ता, लेकिन मेरे अनुभव से पता चला है कि प्रत्येक चरण एक्सकोड को उचित कार्य क्रम में वापस लाने में एक भूमिका निभाता है। इसलिए, मैं किसी भी कदम को छोड़ने या उनके आदेश को बदलने की अनुशंसा नहीं करता हूं।

इसके साथ, यदि आप नीचे दिए गए चरणों को ट्विक करने की आवश्यकता को खोजते हैं, तो कृपया एक टिप्पणी पोस्ट करें ... एक्सकोड लगातार बदलता है इसलिए इन चरणों को समय के साथ-साथ बदलाव की भी आवश्यकता हो सकती है।

XCode दुर्घटनाओं के बाद:

1) सिम्युलेटर अभी भी आईओएस Simulator- चयन करने के लिए> बंद करने से पहले सामग्री और सेटिंग्स रीसेट सुनिश्चित करें कि चल रहा है।

2) बंद सिम्युलेटर (सीएमडी-क्यू)

3) खिड़की -> आयोजक ->, किसी भी डिवाइस पर ली गई डेटा

4) डिबगिंग तो हटाएँ डिवाइस और रिबूट से एप्लिकेशन को हटाना डिवाइस पूरी तरह से।

5) लॉन्च XCode

6) निकालें सभी breakpoints

7) उत्पाद -> (नीचे ऑल्ट/विकल्प कुंजी पकड़) स्वच्छ फ़ोल्डर बिल्ड

8) उत्पाद -> स्वच्छ

9) फिर से के माध्यम से बंद XCode XCode-> छोड़ें XCode (नोट: एक सुंदर बाहर निकलें होना चाहिए ताकि XCode ठीक से पूर्ण शटडाउन/सफाई चक्र कर सकते हैं)

0,123,

10) अपने मैक

11 रिबूट) लॉन्च Xcode

12) यदि सिम्युलेटर में चल रहा है, एक अलग डिवाइस से जब यह दुर्घटनाग्रस्त हो गया अनुकरण करने के लिए चुनें।

13)) अपने ऐप का परीक्षण चालन (कोई breakpoints साथ

14) सब कुछ ठीक हो जाता है, एक breakpoints (एक अच्छा प्रारंभिक बिंदु सभी अपवाद हमेशा होता है) जोड़ना शुरू करो।

जय हो मेरी खंड (उर्फ "Corbomite मैन्युवर"): अगर कर सब से ऊपर तो काम नहीं किया उपरोक्त सभी चरणों का पुन: प्रदर्शन है, लेकिन चरण 9 और 10 के बीच निम्न चरण सम्मिलित करें: 9 ए) एक्सकोड ऐप हटाएं और एक्सकोड पुनः स्थापित करें।

+0

मैंने उन सभी को किया, लेकिन मेरे पास इसे अधिक से अधिक दस्तावेज करने के लिए धन्यवाद। ऐसा लगता है कि ऊपर सूचीबद्ध सब कुछ करने के बाद भी, अंततः यह फिर से दुर्घटनाग्रस्त हो जाएगा। * उदास चेहरा * कार्यों में 6.2 है, शायद यह अधिक स्थिरता लाएगा। –

+1

उपरोक्त वास्तव में एक्सकोड को ठीक स्थिति में ठीक करने के लिए ठीक है। हालांकि, खराब स्थिति का कारण आपके द्वारा चलाए जा रहे कोड से संबंधित हो सकता है ... उदाहरण के लिए, कंसोल पर लॉगिंग करने के लिए बहुत से लोग अनिवार्य रूप से एक्सकोड को क्रैशिंग शुरू कर देंगे। इसके अलावा, सी/सी ++ (और यहां तक ​​कि ओबीजेसी) में खराब मेमोरी पॉइंटर्स किसी भी पर्यावरण को समय के साथ थोड़ा भद्दा बना सकते हैं (यहां तक ​​कि पकड़े जाने पर भी)। प्वाइंट यह है कि उपर्युक्त एक्सकोड को वापस सामान्य करने के लिए है ... जिस बिंदु पर मैं इस परियोजना के मुद्दे को कम करने की कोशिश करता हूं जिसे आप चलाने की कोशिश कर रहे हैं। यानी आपको XCode स्थिर रहने के लिए अभी भी रूट कारण को ठीक करने की आवश्यकता है। – Questor

+0

अच्छा बिंदु! मुझे वही मिला है। पूरी चीज को साफ करना कभी-कभी दुर्घटना के मूल कारण को खोजने में मदद कर सकता है। स्पष्टीकरण के लिए धन्यवाद। –

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