ऐप समीक्षा द्वारा प्राप्त क्रैश को पुन: उत्पन्न नहीं कर सकता है। क्या कोई इस क्रैश रिपोर्ट को समझने में मदद कर सकता है?

ऐप्पल ने हमारे आईफोन ऐप को खारिज कर दिया, यह दिखाता है कि यह आईपैड पर दुर्घटनाग्रस्त हो गया। हम 3 अलग-अलग आईपैड पर दुर्घटना को पुन: पेश नहीं कर पाए और पुष्टि करने के लिए कहा। ऐप्पल वापस आ गया कि उन्होंने आईफोन 4 पर दुर्घटना का उत्पादन किया (हालांकि लॉग आईफोन 3 दिखाता है)। हम इसे पुन: पेश नहीं कर सकते ...ऐप समीक्षा द्वारा प्राप्त क्रैश को पुन: उत्पन्न नहीं कर सकता है। क्या कोई इस क्रैश रिपोर्ट को समझने में मदद कर सकता है?

वे क्रैश उत्पन्न करते हैं: लॉन्च ऐप। मुझे पहले को देखने दें चुनें। ऐप दुर्घटनाग्रस्त

लॉग वे हमें वापस भेज दिया क्षुधा खुद पद्धतियों को बुलाया में से किसी को नहीं दिखा रहा है:

ncident Identifier: 8B5E90DE-99FD-4279-B634-2C777209F2B3 
CrashReporter Key: 6e9ccd0fcdc29915ebe22fb7376bd343cdcc252a 
Hardware Model:  iPhone3,1 
Process:   Snug [297] 
Path:   /var/mobile/Applications/DB3EFF00-7E5E-492A-9108-1341B6371B0D/Snug.app/Snug 
Identifier:  Snug 
Version:   ??? (???) 
Code Type:  ARM (Native) 
Parent Process: launchd [1] 

Date/Time:  2012-09-09 13:00:32.642 -0700 
OS Version:  iPhone OS 5.1.1 (9B206) 
Report Version: 104 

Exception Type: EXC_CRASH (SIGABRT) 
Exception Codes: 0x00000000, 0x00000000 
Crashed Thread: 6 

Thread 0 name: Dispatch queue: com.apple.main-thread 
Thread 0: 
0 libsystem_kernel.dylib   0x319e7660 __semwait_signal_nocancel + 24 
1 libsystem_c.dylib    0x3410b4da nanosleep$NOCANCEL + 118 
2 libsystem_c.dylib    0x340dd3a0 usleep$NOCANCEL + 44 
3 libsystem_c.dylib    0x340dd2b6 abort + 118 
4 Snug       0x001f8760 uncaught_exception_handler + 12 
5 CoreFoundation     0x37830950 __handleUncaughtException + 68 
6 libobjc.A.dylib     0x3553533e _objc_terminate + 122 
7 libc++abi.dylib     0x36f683be safe_handler_caller(void (*)()) + 70 
8 libc++abi.dylib     0x36f6844a std::terminate() + 14 
9 libc++abi.dylib     0x36f6981e __cxa_rethrow + 82 
10 libobjc.A.dylib     0x355352a2 objc_exception_rethrow + 6 
11 CoreFoundation     0x37786506 CFRunLoopRunSpecific + 398 
12 CoreFoundation     0x37786366 CFRunLoopRunInMode + 98 
13 GraphicsServices    0x33f45432 GSEventRunModal + 130 
14 UIKit       0x31532cce UIApplicationMain + 1074 
15 Snug       0x000f590c main (main.m:16) 
16 Snug       0x000f58c0 start + 32 

Thread 1 name: Dispatch queue: com.apple.libdispatch-manager 
Thread 1: 
0 libsystem_kernel.dylib   0x319d73a8 kevent + 24 
1 libdispatch.dylib    0x3095cea4 _dispatch_mgr_invoke + 708 
2 libdispatch.dylib    0x3095cbc2 _dispatch_mgr_thread + 30 

Thread 2: 
0 libsystem_kernel.dylib   0x319e7cd4 __workq_kernreturn + 8 
1 libsystem_c.dylib    0x3409ff36 _pthread_wqthread + 610 
2 libsystem_c.dylib    0x3409fcc8 start_wqthread + 0 

Thread 3: 
0 libsystem_kernel.dylib   0x319e7cd4 __workq_kernreturn + 8 
1 libsystem_c.dylib    0x3409ff36 _pthread_wqthread + 610 
2 libsystem_c.dylib    0x3409fcc8 start_wqthread + 0 

Thread 4 name: WebThread 
Thread 4: 
0 libsystem_kernel.dylib   0x319d7004 mach_msg_trap + 20 
1 libsystem_kernel.dylib   0x319d71fa mach_msg + 50 
2 CoreFoundation     0x378043ec __CFRunLoopServiceMachPort + 120 
3 CoreFoundation     0x37803124 __CFRunLoopRun + 876 
4 CoreFoundation     0x3778649e CFRunLoopRunSpecific + 294 
5 CoreFoundation     0x37786366 CFRunLoopRunInMode + 98 
6 WebCore       0x3312fc9c RunWebThread(void*) + 396 
7 libsystem_c.dylib    0x340a572e _pthread_start + 314 
8 libsystem_c.dylib    0x340a55e8 thread_start + 0 

Thread 5 name: com.apple.NSURLConnectionLoader 
Thread 5: 
0 libsystem_kernel.dylib   0x319d7004 mach_msg_trap + 20 
1 libsystem_kernel.dylib   0x319d71fa mach_msg + 50 
2 CoreFoundation     0x378043ec __CFRunLoopServiceMachPort + 120 
3 CoreFoundation     0x37803124 __CFRunLoopRun + 876 
4 CoreFoundation     0x3778649e CFRunLoopRunSpecific + 294 
5 CoreFoundation     0x37786366 CFRunLoopRunInMode + 98 
6 Foundation      0x38016bb2 +[NSURLConnection(Loader) _resourceLoadLoop:] + 302 
7 Foundation      0x38016a7a -[NSThread main] + 66 
8 Foundation      0x380aa58a __NSThread__main__ + 1042 
9 libsystem_c.dylib    0x340a572e _pthread_start + 314 
10 libsystem_c.dylib    0x340a55e8 thread_start + 0 

Thread 6 Crashed: 
0 libsystem_kernel.dylib   0x319e7cd4 __workq_kernreturn + 8 
1 libsystem_c.dylib    0x3409ff36 _pthread_wqthread + 610 
2 libsystem_c.dylib    0x3409fcc8 start_wqthread + 0 

Thread 7: 
0 libsystem_kernel.dylib   0x319e7cd4 __workq_kernreturn + 8 
1 libsystem_c.dylib    0x3409ff36 _pthread_wqthread + 610 
2 libsystem_c.dylib    0x3409fcc8 start_wqthread + 0 

Thread 8: 
0 libsystem_kernel.dylib   0x319e7cd4 __workq_kernreturn + 8 
1 libsystem_c.dylib    0x3409ff36 _pthread_wqthread + 610 
2 libsystem_c.dylib    0x3409fcc8 start_wqthread + 0 

Thread 9 name: com.apple.CFSocket.private 
Thread 9: 
0 libsystem_kernel.dylib   0x319e7570 __select + 20 
1 CoreFoundation     0x3780863a __CFSocketManager + 726 
2 libsystem_c.dylib    0x340a572e _pthread_start + 314 
3 libsystem_c.dylib    0x340a55e8 thread_start + 0 

Thread 6 crashed with ARM Thread State: 
    r0: 0x00000004 r1: 0x00000000  r2: 0x00000000  r3: 0x00000000 
    r4: 0x0c8cc800 r5: 0x0036a08c  r6: 0x04339000  r7: 0x04338fe0 
    r8: 0x3f29fd30 r9: 0x00000000  r10: 0x3f29fd50  r11: 0x00000000 
    ip: 0x00000170 sp: 0x04338fc0  lr: 0x3409ff3d  pc: 0x319e7cd4 
    cpsr: 0x40000010

किसी को भी इस क्रैश रिपोर्ट के साथ हमें प्रबुद्ध कर सकते हैं?

अद्यतन:

हम अपने ऐप्लिकेशन समीक्षा टीम nagged हमें सांत्वना ट्रेस भेजने के लिए, उन्होंने किया। ट्रेस में यह स्पष्ट था कि एक स्ट्रिंग श्रेणी विधि में एक कॉल किया जा रहा है जो मौजूद नहीं है।

गलती यह थी कि विशेष श्रेणी कार्यान्वयन फ़ाइल हमारे रिलीज लक्ष्य में नहीं जोड़ा गया था। तो सब कुछ पूरी तरह से काम किया लेकिन जब ऐप संग्रहीत किया गया था एक कार्यान्वयन फ़ाइल गायब था।

स्रोत

2012-09-10 theVurt

एप्लिकेशन लॉन्च और क्रैश करने में कितना समय लगता है? ऐसा लगता है कि आपने लॉन्च – Stavash

लॉन्च करने के लिए स्वीकार्य समय पार कर लिया है स्प्लैशपृष्ठ से पहली स्क्रीन (मानक लगता है) से जाने के लिए लगभग एक सेकंड के बारे में। फिर, वे स्पष्ट रूप से ऐप को क्रैश करने पर क्लिक करके "मुझे पहले चारों ओर देखने दें" बटन पर पहुंचते हैं। आप इस निष्कर्ष पर कैसे आए? – theVurt

अपवाद क्या है यह जानने के लिए थोड़े उपयोगी होंगे। शायद यह क्रैश समय पर कंसोल लॉग में मुद्रित हो जाता है। – Bryan

के लिए

लिंक दुर्भाग्य से इस लॉग नहीं लगती है जैसे कि यह बहुत उपयोगी हो जाएगा - यह सिर्फ मुख्य थ्रेड एक अपवाद है कि किया जा रहा एक और धागे से फिर से फेंक दिया है हैंडलिंग पता चलता है; वह धागा लॉग के समय कुछ और करने के लिए चला गया है।

आप RestKit लूप के बारे में अपने संदेह का उल्लेख करते हैं और संभावना NSOperation अपवाद फेंक रहा है। यह संभव है और एक चेक डालने के लायक है (और अपनी उंगलियों को पार करना कि यह कुछ और नहीं तोड़ता है ...), लेकिन शायद यह ऐप समीक्षा टीम से प्रार्थना करने का समय है कि आपको पुन: पेश करने के लिए बेहतर कदम दें। देखें कि क्या आप नीचे जो कुछ भी कर रहे हैं उसे पिन कर सकते हैं। काश मैं आपके लिए एक बेहतर जवाब था, लेकिन मुझे लगता है कि आप ऐप के इस हिस्से में पृष्ठभूमि में क्या कर रहे हैं और पुन: पेश करने के लिए लापता चरणों को समझने की कोशिश कर रहे हैं, यह सब कुछ आप कर सकते हैं। । सौभाग्य!

स्रोत

2012-09-11 13:01:47

दुर्घटना शीर्ष सबसे चुस्त लाइन 4

Thread 0 name: Dispatch queue: com.apple.main-thread 
Thread 0: 
0 libsystem_kernel.dylib   0x319e7660 __semwait_signal_nocancel + 24 
1 libsystem_c.dylib    0x3410b4da nanosleep$NOCANCEL + 118 
2 libsystem_c.dylib    0x340dd3a0 usleep$NOCANCEL + 44 
3 libsystem_c.dylib    0x340dd2b6 abort + 118 
4 Snug       0x001f8760 uncaught_exception_handler + 12 
5 CoreFoundation     0x37830950 __handleUncaughtException + 68 
6 libobjc.A.dylib     0x3553533e _objc_terminate + 122 
7 libc++abi.dylib     0x36f683be safe_handler_caller(void (*)()) + 70 
8 libc++abi.dylib     0x36f6844a std::terminate() + 14 
9 libc++abi.dylib     0x36f6981e __cxa_rethrow + 82 
10 libobjc.A.dylib     0x355352a2 objc_exception_rethrow + 6 
11 CoreFoundation     0x37786506 CFRunLoopRunSpecific + 398 
12 CoreFoundation     0x37786366 CFRunLoopRunInMode + 98 
13 GraphicsServices    0x33f45432 GSEventRunModal + 130 
14 UIKit       0x31532cce UIApplicationMain + 1074 
15 Snug       0x000f590c main (main.m:16) 
16 Snug       0x000f58c0 start + 32

वहाँ कम से धागा 0 में हुआ एप्लिकेशन एक अपवाद है जो पकड़ा नहीं किया गया था का कारण बना। रिपोर्ट का प्रतीक करने के लिए बस इसे xCode में खींचें - आपको समीक्षा संस्करण के लिए डीएसवाईएम फ़ाइल की आवश्यकता है। फिर xCode आपको सटीक रेखा दिखाएगा जहां समस्या आई थी। डीएसआईएम प्राप्त करने के लिए आपको "निर्माण और संग्रह" की आवश्यकता है।

इसके अलावा के बाद से दुर्घटना कोड

Exception Type: EXC_CRASH (SIGABRT) 
Exception Codes: 0x00000000, 0x00000000

है दुर्घटना का कारण एक स्मृति पहुँच समस्या है। इस तरह की क्रैश रिपोर्ट कई मामलों में उत्पन्न होती है जहां कोई एक शून्य ऑब्जेक्ट को सरणी या शब्दकोश में डालने का प्रयास करता है। (चूंकि दुर्घटना मुख्य धागे में है और रिपोर्ट के रूप में थ्रेड 6 में नहीं है)

आपके मामले में मुझे कोई स्पष्ट सम्मिलन दिखाई नहीं देता है, हालांकि मैं आपकी मुख्य फ़ाइल के लाइन 16 में शुरू होने वाले तर्क की जांच करता हूं और बाद में । मुझे लगता है कि आप किसी ऑब्जेक्ट तक पहुंच रहे हैं जो इस आमंत्रण के समय मौजूद नहीं है।

स्रोत

2012-09-10 16:32:51 user387184

क्रैश पृष्ठभूमि थ्रेड पर हुआ यह बस है जहां अपवाद बहाल हो रहा है। –

यह पहले से ही एक प्रतीकात्मक लॉग है: -/मैंने xcode का प्रतीक यह प्रतीक है, एप्पल से प्राप्त गैर प्रतीकात्मक एक मानव पठनीय स्टैक निशान नहीं है। @ करल Veazey क्या आप देख सकते हैं? मैं इसे समझ नहीं सकता, मैं मुख्य धागे पर फिर से फेंक देखता हूं और यह करता है। – theVurt

@theVurt हाँ, मैं स्टंप हो गया हूं, यह लॉग मेरे लिए बहुत उपयोगी नहीं लग रहा है :(ऐसा लगता है कि थ्रेड 6 बंद हो गया है और मुख्य धागा फिर से फेंकने के दौरान कुछ और करना शुरू कर दिया। मैं बस खोजने की कोशिश करता पृष्ठभूमि से लॉन्च/रिटर्न पर पृष्ठभूमि थ्रेड पर आप क्या कर रहे हैं; और शायद देखें कि क्या आप कुछ भी कर रहे हैं जो आप अपने डीबग/एडमोक बिल्ड में अलग-अलग कर रहे हैं। –

आप नीचे दिए गए का उपयोग कर क्रैश रिपोर्ट का विश्लेषण कर सकते

सेब से क्रैश रिपोर्ट का विश्लेषण करने के चरण:

कॉपी रिहाई .app फ़ाइल जो डालें, पर बनाया गया था कि .dSYM फाइल करने के लिए दिया गया था रिलीज का समय और क्रैश रिपोर्ट एपीएलई से एक फ़ोल्डर में प्राप्त होती है।

खुली टर्मिनल आवेदन और ऊपर बनाया (सीडी आदेश का उपयोग) फ़ोल्डर

रफ -arch ARMv7 -ओ YOURAPP.app/YOURAPP MEMORY_LOCATION_OF_CRASH में जाते हैं। स्मृति स्थान वह होना चाहिए जिस पर ऐप रिपोर्ट के अनुसार दुर्घटनाग्रस्त हो।

पूर्व: atos -arch armv7 -o 'ऐप नाम।ऐप '/' ऐप नाम '0x0003b508

यह आपको सटीक रेखा, विधि नाम दिखाएगा जिसके परिणामस्वरूप दुर्घटना हुई।

पूर्व: [classname functionName:]; -510

Symbolicating आईपीए

अगर हम symbolicating के लिए आईपीए का उपयोग - बस ज़िप के साथ विस्तार .ipa का नाम बदलने के लिए, यह निकालने फिर हम एक पेलोड फ़ोल्डर जो एप्लिकेशन को शामिल कर सकते हैं। इस मामले में हमें .dSYM फ़ाइल की आवश्यकता नहीं है। इस Symbolicating iPhone App Crash Reports

स्रोत

2012-09-11 08:33:06

मैंने एक्सकोड का उपयोग अपनी मशीन पर संग्रहित डीडीएसवाईएम के साथ रिपोर्ट करने के लिए किया है जो एक संग्रह में था आईपीए का उत्पादन करने के लिए इस्तेमाल किया गया है मेरे पास आईपीए जमा नहीं है। मैं इस धारणा के तहत था कि यह पहले से ही प्रतीक था। – theVurt

उत्तर

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