lastly I uploaded app to appstore. I am using also Flurry analytics, and few errors were captured there.
I tried to attach dSYM file to make it more readable, however I am not sure which part of such log changes into human readable text.
Other thing here: I don't see any line that points to one of my class files (implemenation).
So my questions are
- How can I get some more information from such report?
- Is is true, that the app really crashed on user device? Or maybe such error was invisible for a user?
- Is it possible that the app didn't crash but maybe user killed its process?
Thanks
Here is the crash report
Hardware Model: iPhone3,3
Process: my-app [560]
Path: /var/mobile/Applications/3539397F-14A1-4802-A388-1D5070404D98/my id
Identifier: /my id
Version: 1.3
Code Type: ARM
Parent Process: launchd [1]
Exception Type: SIGSEGV
Exception Codes: SEGV_ACCERR at 0x70000008
Crashed Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x34dde5b0 +[Protocol load] + 663
1 UIKit 0x3471b4a7 0x34699000 + 533671
2 UIKit 0x346b1abb 0x34699000 + 101051
3 UIKit 0x347268d7 0x34699000 + 579799
4 QuartzCore 0x34cdabd9 -[CALayer dealloc] + 1244
5 libdispatch.dylib 0x3793d4b7 0x3793c000 + 5303
6 libdispatch.dylib 0x3793edcb -[OS_object release] + 274
7 CoreFoundation 0x3826af3b +[__NSCFLocale automaticallyNotifiesObserversForKey:] + 12398
8 CoreFoundation 0x381ddebd -[__NSDate timeIntervalSinceReferenceDate] + 500
9 CoreFoundation 0x381ddd49 -[__NSDate timeIntervalSinceReferenceDate] + 128
10 GraphicsServices 0x3887a2eb 0x38875000 + 21227
11 UIKit 0x346f0301 0x34699000 + 357121
12 my-app 0x0012987b -[ASIHTTPRequest setSynchronous:] + 86
Thread 1:
0 libsystem_kernel.dylib 0x3568c648 0x3568b000 + 5704
1 libdispatch.dylib 0x3793fdf8 -[OS_object _dispose] + 579
Thread 2:
0 libsystem_kernel.dylib 0x3568beb4 0x3568b000 + 3764
1 CoreFoundation 0x3826c045 +[__NSCFLocale automaticallyNotifiesObserversForKey:] + 16760
2 CoreFoundation 0x3826ada3 +[__NSCFLocale automaticallyNotifiesObserversForKey:] + 11990
3 CoreFoundation 0x381ddebd -[__NSDate timeIntervalSinceReferenceDate] + 500
4 CoreFoundation 0x381ddd49 -[__NSDate timeIntervalSinceReferenceDate] + 128
5 WebCore 0x3689ca75 +[WebScriptObject initialize] + 608
6 libsystem_c.dylib 0x364f5311 0x364e4000 + 70417
Thread 3:
0 libsystem_kernel.dylib 0x3568beb4 0x3568b000 + 3764
1 CoreFoundation 0x3826c045 +[__NSCFLocale automaticallyNotifiesObserversForKey:] + 16760
2 CoreFoundation 0x3826ada3 +[__NSCFLocale automaticallyNotifiesObserversForKey:] + 11990
3 CoreFoundation 0x381ddebd -[__NSDate timeIntervalSinceReferenceDate] + 500
4 CoreFoundation 0x381ddd49 -[__NSDate timeIntervalSinceReferenceDate] + 128
5 Foundation 0x3264cbcd +[NSURLConnection _resourceLoadLoop:] + 308
6 Foundation 0x326d067d -[NSThread description] + 1096
7 libsystem_c.dylib 0x364f5311 0x364e4000 + 70417
Thread 4:
0 libsystem_kernel.dylib 0x3568beb4 0x3568b000 + 3764
1 CoreFoundation 0x3826c045 +[__NSCFLocale automaticallyNotifiesObserversForKey:] + 16760
2 CoreFoundation 0x3826ada3 +[__NSCFLocale automaticallyNotifiesObserversForKey:] + 11990
3 CoreFoundation 0x381ddebd -[__NSDate timeIntervalSinceReferenceDate] + 500
4 CoreFoundation 0x381ddd49 -[__NSDate timeIntervalSinceReferenceDate] + 128
5 my-app 0x001275eb +[ASIHTTPRequest runRequests] + 170
6 Foundation 0x326d067d -[NSThread description] + 1096
7 libsystem_c.dylib 0x364f5311 0x364e4000 + 70417
Thread 5:
0 libsystem_kernel.dylib 0x3569c594 0x3568b000 + 71060
1 libsystem_c.dylib 0x364f5311 0x364e4000 + 70417
Thread 6:
0 libsystem_kernel.dylib 0x3568beb4 0x3568b000 + 3764
1 CoreFoundation 0x3826c045 +[__NSCFLocale automaticallyNotifiesObserversForKey:] + 16760
2 CoreFoundation 0x3826ada3 +[__NSCFLocale automaticallyNotifiesObserversForKey:] + 11990
3 CoreFoundation 0x381ddebd -[__NSDate timeIntervalSinceReferenceDate] + 500
4 CoreFoundation 0x381ddd49 -[__NSDate timeIntervalSinceReferenceDate] + 128
5 Foundation 0x3262378f +[NSNotification allocWithZone:] + 334
6 Foundation 0x326c705d +[NSPropertyListSerialization propertyListWithStream:options:format:error:] + 9132
7 my-app 0x0013a9ad +[TFURLConnectionOperation _runNetworkThread:] + 140
8 Foundation 0x326d067d -[NSThread description] + 1096
9 libsystem_c.dylib 0x364f5311 0x364e4000 + 70417
Thread 7:
0 libsystem_kernel.dylib 0x3569cd98 0x3568b000 + 73112
1 libsystem_c.dylib 0x364eaa16 0x364e4000 + 27158
Thread 8:
0 libsystem_kernel.dylib 0x3569cd98 0x3568b000 + 73112
1 libsystem_c.dylib 0x364eaa16 0x364e4000 + 27158
Thread 0 crashed with ARM Thread State:
r0: 0x1fc42250 r1: 0x34b1bee8 r2: 0x2fdf0d60 r3: 0x348a80d5
r4: 0x70000000 r5: 0x1fc42250 r6: 0x1fc42360 r7: 0x2fdf0e3c
r8: 0x1ed3c720 r9: 0x0d2c6fba r10: 0x1fc1b290 r11: 0x00000001
ip: 0x3b9a7d64 sp: 0x2fdf0db4 lr: 0x3471b84b pc: 0x34dde5b0
cpsr: 0x20000030
Regarding your questions:
Question 1: How can I get some more information from such report?
Answer:
The signal is SIGSEGV which basically means a segmentation fault. There are several possible reasons for such a crash, e.g. a overreleased object, an non initialised pointer or code that writes directly into memory.
The crashing thread shows a dealloc call in the stack trace. This is hinting the crash was caused while an object was deallocated.
Lots of background threads are running a network operation with ASIHTTPRequest with similar calls in the stack traces.
There are a lot of mentions of automaticallyNotifiesObserversForKey which hints that Key-Value-Observing is involved. Maybe there is an observer registered to a key, and the observer is already deallocated. It is even more tricky, since the notifications are triggered from a background thread! E.g. doing networking in the background and observing with an object on the main thread. It is pretty easy to get such crashes in these scenarios if you don't make sure the object on the main thread lives long enough.
It is really really really strange that multiple background threads have nearly identical stack traces with even identical memory addresses for individual stack frames.
Assumption: If you can't reproduce this problem you might not find the cause. I suspect it is somehow related to ASIHTTPRequest and either its internal key-value-coding handling or your own use of that. So I would replace that library e.g. with AFNetworking or using the plain networking stack provided by iOS. In addition if you are using key-value-coding, check the code regarding multi-threading safety.
Question 2: Is is true, that the app really crashed on user device?
Yes, you get these reports only on real app crashes.
Question 3: Or maybe such error was invisible for a user?
No, SIGSEGV is a real crash of your app. Invisible would be, if you catch an exception in your code and still generate a report and send it over. But as far as I know Flurry doesn't provide this feature, you obviously didn't implement it and that crash is not caused by an exception either. So this is impossible.
Question 4: Is it possible that the app didn't crash but maybe user killed its process?
If apps get killed, you won't get a crash report by Flurry. Kills are triggered by iOS and in-process-crash reporting libraries (which means every 3rd party crash reporting service) can never ever create a report for these.
Additional note: Exception breakpoints (as others suggested) don't help on this type of crash, since it did not crash because an exception occured.
may be ask directly at flurry - crashanalytics#flurry.com ? I hope they can better help you with it.
take a look at your places there you do internet requests - I think it's something in this place.
For better testing I think you need to find iPhone3.3 version (as I know it's verizon iphone 4) and try to debug your app directly on this device.
Related
I have a small app made with SpriteKit and i receive EXC_RESOURCE error all the time and i really don't know. I want to see crash log , but Xcode doesn't symbolicate correct.
I need to see Thread 0 , but it is the only one who isn't symbolicate.
Exception Type: EXC_RESOURCE
Exception Subtype: WAKEUPS
Exception Message: (Limit 150/sec) Observed 379/sec over 300 secs
Triggered by Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Attributed:
0 libobjc.A.dylib 0x33ef1a54 0x33ecf000 + 141908
1 libobjc.A.dylib 0x33ed4a24 0x33ecf000 + 23076
2 CoreFoundation 0x2661beec 0x26615000 + 28396
3 CoreFoundation 0x266b655e 0x26615000 + 660830
4 CoreFoundation 0x266b67b4 0x26615000 + 661428
5 UIKit 0x29e6adec 0x29bcd000 + 2743788
6 UIKit 0x29c106a2 0x29bcd000 + 276130
7 UIKit 0x29e4ce8a 0x29bcd000 + 2621066
8 UIKit 0x29bdb3d4 0x29bcd000 + 58324
9 CoreFoundation 0x266e1d54 0x26615000 + 838996
10 CoreFoundation 0x266e1162 0x26615000 + 835938
11 CoreFoundation 0x266df7c8 0x26615000 + 829384
12 CoreFoundation 0x2662d3bc 0x26615000 + 99260
13 CoreFoundation 0x2662d1ce 0x26615000 + 98766
14 GraphicsServices 0x2da2b0a4 0x2da22000 + 37028
15 UIKit 0x29c3b7ac 0x29bcd000 + 452524
16 Annoying Bird 0x00071f5c 0x54000 + 122716
17 libdyld.dylib 0x34455aac 0x34454000 + 6828
Thread 1 name: Dispatch queue: com.apple.libdispatch-manager
Thread 1:
0 libsystem_kernel.dylib 0x345082a0 kevent64 + 24
1 libdispatch.dylib 0x344419fc _dispatch_mgr_invoke + 276
2 libdispatch.dylib 0x3443720e _dispatch_mgr_thread + 34
Thread 2 name: AURemoteIO::IOThread
Thread 2:
0 libsystem_kernel.dylib 0x345084f0 mach_msg_trap + 20
1 libsystem_kernel.dylib 0x345082e4 mach_msg + 36
2 AudioToolbox 0x25e9599a AURemoteIO::IOThread::Run() + 102
3 AudioToolbox 0x25e99094 AURemoteIO::IOThread::Entry(void*) + 4
4 AudioToolbox 0x25dcd9e2 CAPThread::Entry(CAPThread*) + 206
5 libsystem_pthread.dylib 0x34598e90 _pthread_body + 136
6 libsystem_pthread.dylib 0x34598e02 _pthread_start + 114
7 libsystem_pthread.dylib 0x34596b8c thread_start + 4
Thread 3:
0 libsystem_kernel.dylib 0x3451c9cc __workq_kernreturn + 8
1 libsystem_pthread.dylib 0x34596ea8 _pthread_wqthread + 788
2 libsystem_pthread.dylib 0x34596b80 start_wqthread + 4
Thread 4:
0 libsystem_kernel.dylib 0x3451c9cc __workq_kernreturn + 8
1 libsystem_pthread.dylib 0x34596ea8 _pthread_wqthread + 788
2 libsystem_pthread.dylib 0x34596b80 start_wqthread + 4
Thread 0 crashed with ARM Thread State (32-bit):
r0: 0x00000000 r1: 0x3481da04 r2: 0x16664d50 r3: 0x01001380
r4: 0x00000000 r5: 0x3481da04 r6: 0x16664d50 r7: 0x00183450
r8: 0x00000030 r9: 0xffffffff r10: 0x00000013 r11: 0x347fa3c0
ip: 0x36b8a198 sp: 0x00183444 lr: 0x33ed4a29 pc: 0x33ef1a54
cpsr: 0x20000010
Expanding on my earlier comment in an answer, as it won't fit in the comment anymore.
In your crash report, look at the first line under Binary Images
EG>
Binary Images:
0xb3000 - 0x242fff AppName armv7 <6daf5fd2c9e23af786cd580ef39b5b82> /private/var/mobile/Containers/Bundle/Application/E83D554F-BD3A-47CF-8753-AAACB0BDDF33/AppName.app/AppName
The hash between the angle brackets <> is the build UUID of the build that produced the crash log. We'll call that CrashLogUUID later.
Next, in terminal, change to your archived app directory and execute:
dwarfdump --uuid dSYMs/AppName.app.dSYM
You'll get back a number of UUIDs, one for each slice/architecture in the app.
Confirm that the CrashLogUUID you see in the crash log is listed in the UUID list for the app. If you don't see a match, you have the wrong archive/dSYM.
If it's the wrong dSYM, you can search for the correct one. You need to adjust the format of your CrashLogUUID from above, make it all upper case, and add hyphens to fit the standard UUID format: 8chars-4chars-4chars-4chars-12chars. Lets call this CrashLogUUIDFormatted.
Due to a bug in Mavericks, you will need to copy all of your archived projects out of the ~/Library folder and into somewhere that Spotlight indexes, such as your Desktop. In Mavericks, Spotlight won't index under ~/Library even if you specifically add it (rdar://17169292 fixed in Yosemite).
Now in terminal, enter:
mdfind "com_apple_xcode_dsym_uuids == CrashLogUUIDFormatted"
That will list the correct location of the app archive and/or dSYM related to your crash log. If it comes back empty, Spotlight can't find the correct build and you many not have it on your system.
Once you have the correct dSYM, you can either have Xcode try and do the symbolication automatically again (if it wasn't finding it with mdfind earlier but can do now, this will work). Or you can symbolicate it manually with the following command:
/Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash -v -o output.log yourCrashLog.crash AppName.dSYM
That will take your crash log and your dSYM and create a symbolicated crash log called output.log.
Hope that helps!
I'm posting here in hope for advice from more experienced programmers (in general & with Cocos2D specifically).
I have an old-ish project that is using Cocos2D v2.1 in a couple of places, otherwise it's standard UIKit. I updated it to be compliant with arm64, or so I thought, and managed to remove any compiler warnings, and run the app successfully on the simulator. However, I just got a bug report form an iPad Air user that the Cocos2d portion of the app is crashing.
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000010
Triggered by Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x00000001995101d0 0x1994f8000 + 98768
1 0x000000010014e820 -[CCTimer update:] + 152
2 0x0000000100152140 -[CCScheduler update:] + 420
3 0x000000010016ab30 -[CCDirectorIOS drawScene] + 172
Like I say, there are no compiler warnings and it all works on the simulator, so I'm kinda stuck as to how to fix it. I know that the usual two options would be to
1. remove arm64
2. upgrade to Cocos2D v3.0
However, I use Cocos2D only for a tiny portion of the app, so I was hoping that perhaps I am missing a simple fix. I'm pretty inexperienced with Cocos2D and debugging in general, so I'm hoping for some advice if this is a lost cause and I should better spend my time on one of the other 2 options, or perhaps there is something simple that I can tweak that I am missing right now. I did browse through the CCTimer update: methods, and the only thing that stood out were a few floats in the code, that I know can be problematic between 32/64 bit, but without a compiler warning I am at a loss.
UPDATE
So it gets mysteriouser and mysteriouser. I bought a brand new iPad Air to test this locally instead of on the simulator, and... it works. No crashes. Does the user perhaps simply have a defective device? I noticed that the Exception is thrown at KERN_INVALID_ADDRESS at 0x0000000000000010 which looks somewhat odd. Most of similar crash reports I've seen online have entirely different addresses that look much more random.
UPDATE 2
More mysteries. While the local version works on the device (run via XCode), the actually downloaded app from the AppStore does crash! I was able to capture some more info about it from the Device Logs:
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000010
Triggered by Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x0000000196c041d0 objc_msgSend + 16
1 0x00000001001da820 -[CCTimer update:] + 152
2 0x00000001001de140 -[CCScheduler update:] + 420
3 0x00000001001f6b30 -[CCDirectorIOS drawScene] + 172
4 QuartzCore 0x000000018cf40cb8 CA::Display::DisplayLinkItem::dispatch() + 32
5 QuartzCore 0x000000018cf40ac4 CA::Display::DisplayLink::dispatch_items(unsigned long long, unsigned long long, unsigned long long) + 296
6 IOKit 0x000000018b23be70 IODispatchCalloutFromCFMessage + 360
7 CoreFoundation 0x000000018a2ec8dc __CFMachPortPerform + 188
8 CoreFoundation 0x000000018a2fae8c __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 52
9 CoreFoundation 0x000000018a2fadec __CFRunLoopDoSource1 + 440
10 CoreFoundation 0x000000018a2f9010 __CFRunLoopRun + 1616
11 CoreFoundation 0x000000018a239c1c CFRunLoopRunSpecific + 448
12 GraphicsServices 0x000000018fec9c08 GSEventRunModal + 164
13 UIKit 0x000000018d36afd8 UIApplicationMain + 1152
14 0x00000001000f4994 main (main.m:16)
15 libdyld.dylib 0x00000001971e7a9c start + 0
Thread 1:
0 libsystem_kernel.dylib 0x00000001972c9aa8 kevent64 + 8
1 libdispatch.dylib 0x00000001971cd998 _dispatch_mgr_thread + 48
Thread 2:
0 libsystem_kernel.dylib 0x00000001972c9ca0 mach_msg_trap + 8
1 CoreFoundation 0x000000018a2fab70 __CFRunLoopServiceMachPort + 180
2 CoreFoundation 0x000000018a2f8d00 __CFRunLoopRun + 832
3 CoreFoundation 0x000000018a239c1c CFRunLoopRunSpecific + 448
4 AudioToolbox 0x0000000189aedabc GenericRunLoopThread::Entry(void*) + 156
5 AudioToolbox 0x0000000189ade278 CAPThread::Entry(CAPThread*) + 136
6 libsystem_pthread.dylib 0x0000000197363e18 _pthread_body + 164
7 libsystem_pthread.dylib 0x0000000197363d70 _pthread_start + 136
8 libsystem_pthread.dylib 0x0000000197361550 thread_start + 0
Thread 3:
0 libsystem_kernel.dylib 0x00000001972e2e74 __workq_kernreturn + 8
1 libsystem_pthread.dylib 0x0000000197361548 start_wqthread + 0
Thread 4:
0 libsystem_kernel.dylib 0x00000001972e2e74 __workq_kernreturn + 8
1 libsystem_pthread.dylib 0x0000000197361548 start_wqthread + 0
Baffled.
Definitely remove arm64 from your project build settings (architecture, valid architectures) because cocos2d-iphone prior to v3 is not compatible with 64-bit builds even if you do not get compiler warnings/errors. There are some nasty potential issues hidden away.
If you do not receive compiler warnings I think it's likely that the 32/64 bit compatibility issues warnings are simply not enabled in your project/target (specifically the cocos2d-iphone target if it's in a separate target). In stock v2.1 of cocos2d there should actually be plenty of such warnings, though it may depend on your iOS Deployment target (for a test try setting it to iOS 7.1 which will give you the most warnings, including many "deprecation" warnings).
You can also perform an Analyze build to point out potential issues (and some false alerts, too).
Apple rejected my app today, I tried to follow the crash log they sent but I couldn't find the source of the crash, I tested my app on two physical phones:
1- iphone 4
2- iphone 5
and I tested it on xcode simulators:
1-Ipad
2-Ipad Retina
3-Ipad Retina (64-bit)
and it works fine on all of them.
this is what they sent to me
We found that your app crashed on iPad running iOS 7.0.6, which is not in compliance with the App
Store Review Guidelines.
Your app crashed when we:
1) Start the app on a device
2) The app crashes on launch
This occurred when your app was used:
- On Wi-Fi
- On cellular network
and this one of the los they sent to me
Incident Identifier: F0618233-A16F-4782-8B79-3A2AE5D8BFF6
CrashReporter Key: 1db6124687c1282286f546adfc3c54dc0d8ed7ce
Hardware Model: xxx
Process: taptap [266]
Path: /var/mobile/Applications/.....
Identifier: x.x.x
Version: 1.0 (1.0)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2014-02-22 14:32:19.271 -0800
OS Version: iOS 7.0.6 (11B651)
Report Version: 104
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Triggered by Thread: 0
Last Exception Backtrace:
(0x2d9bff46 0x3819c6aa 0x2d9bfe88 0x2e347a66 0x8c47c 0x2d982114 0x2d8f6252 0x2e2dbc28 0x301b1f52
0x3019d4c4 0x3013841a 0x3013771c 0x3019cb38 0x325d5708 0x325d52f2 0x2d98a9da 0x2d98a976 0x2d98914a
0x2d8f3c22 0x2d8f3a06 0x3019bdd4 0x30197044 0x8fde2 0x386a4ab2)
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x3875b1fc __pthread_kill + 8
1 libsystem_pthread.dylib 0x387c4a2e pthread_kill + 54
2 libsystem_c.dylib 0x3870bff8 abort + 72
3 libc++abi.dylib 0x37a3acd2 abort_message + 70
4 libc++abi.dylib 0x37a536e0 default_terminate_handler() + 248
5 libobjc.A.dylib 0x3819c91e _objc_terminate() + 190
6 libc++abi.dylib 0x37a511c4 std::__terminate(void (*)()) + 76
7 libc++abi.dylib 0x37a50d28 __cxa_rethrow + 96
8 libobjc.A.dylib 0x3819c7f2 objc_exception_rethrow + 38
9 CoreFoundation 0x2d8f3c98 CFRunLoopRunSpecific + 636
10 CoreFoundation 0x2d8f3a06 CFRunLoopRunInMode + 102
11 UIKit 0x3019bdd4 -[UIApplication _run] + 756
12 UIKit 0x30197044 UIApplicationMain + 1132
13 taptap 0x0008fde2 0x83000 + 52706
14 libdyld.dylib 0x386a4ab4 start + 0
Thread 1 name: Dispatch queue: com.apple.libdispatch-manager
Thread 1:
0 libsystem_kernel.dylib 0x3874883c kevent64 + 24
1 libdispatch.dylib 0x38689210 _dispatch_mgr_invoke + 228
2 libdispatch.dylib 0x38688f96 _dispatch_mgr_thread$VARIANT$mp + 34
Thread 2:
0 libsystem_kernel.dylib 0x3875bc7c __workq_kernreturn + 8
1 libsystem_pthread.dylib 0x387c1dc6 _pthread_wqthread + 306
2 libsystem_pthread.dylib 0x387c1c80 start_wqthread + 4
Thread 3:
0 libsystem_kernel.dylib 0x3875bc7c __workq_kernreturn + 8
1 libsystem_pthread.dylib 0x387c1dc6 _pthread_wqthread + 306
2 libsystem_pthread.dylib 0x387c1c80 start_wqthread + 4
Thread 4 name: WebThread
Thread 4:
0 libsystem_kernel.dylib 0x3875afa8 __psynch_mutexwait + 24
1 libsystem_pthread.dylib 0x387c1f0a _pthread_mutex_lock + 302
2 WebCore 0x35a6f7f0 _WebTryThreadLock(bool) + 104
3 WebCore 0x35a6f772 WebRunLoopLock(__CFRunLoopObserver*, unsigned long,
void*) + 42
4 CoreFoundation 0x2d98b1ca
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 18
5 CoreFoundation 0x2d988b6c __CFRunLoopDoObservers + 280
6 CoreFoundation 0x2d988f7c __CFRunLoopRun + 932
7 CoreFoundation 0x2d8f3c22 CFRunLoopRunSpecific + 518
8 CoreFoundation 0x2d8f3a06 CFRunLoopRunInMode + 102
9 WebCore 0x35a6e266 RunWebThread(void*) + 414
10 libsystem_pthread.dylib 0x387c3c1a _pthread_body + 138
11 libsystem_pthread.dylib 0x387c3b8a _pthread_start + 98
12 libsystem_pthread.dylib 0x387c1c8c thread_start + 4
Thread 5:
0 libsystem_kernel.dylib 0x38748a8c mach_msg_trap + 20
1 libsystem_kernel.dylib 0x38748888 mach_msg + 44
2 CoreFoundation 0x2d98a7be __CFRunLoopServiceMachPort + 150
3 CoreFoundation 0x2d988ee4 __CFRunLoopRun + 780
4 CoreFoundation 0x2d8f3c22 CFRunLoopRunSpecific + 518
5 CoreFoundation 0x2d8f3a06 CFRunLoopRunInMode + 102
6 libAVFAudio.dylib 0x2c976584 GenericRunLoopThread::Entry(void*) + 124
7 libAVFAudio.dylib 0x2c96a99c CAPThread::Entry(CAPThread*) + 176
8 libsystem_pthread.dylib 0x387c3c1a _pthread_body + 138
9 libsystem_pthread.dylib 0x387c3b8a _pthread_start + 98
10 libsystem_pthread.dylib 0x387c1c8c thread_start + 4
Thread 6:
0 libsystem_kernel.dylib 0x3875bc7c __workq_kernreturn + 8
1 libsystem_pthread.dylib 0x387c1dc6 _pthread_wqthread + 306
2 libsystem_pthread.dylib 0x387c1c80 start_wqthread + 4
Thread 7 name: com.apple.NSURLConnectionLoader
Thread 7:
0 libsystem_kernel.dylib 0x38748a8c mach_msg_trap + 20
1 libsystem_kernel.dylib 0x38748888 mach_msg + 44
2 CoreFoundation 0x2d98a7be __CFRunLoopServiceMachPort + 150
3 CoreFoundation 0x2d988ee4 __CFRunLoopRun + 780
4 CoreFoundation 0x2d8f3c22 CFRunLoopRunSpecific + 518
5 CoreFoundation 0x2d8f3a06 CFRunLoopRunInMode + 102
6 Foundation 0x2e32e2f2 +[NSURLConnection(Loader) _resourceLoadLoop:] + 314
7 Foundation 0x2e3a3c82 __NSThread__main__ + 1058
8 libsystem_pthread.dylib 0x387c3c1a _pthread_body + 138
9 libsystem_pthread.dylib 0x387c3b8a _pthread_start + 98
10 libsystem_pthread.dylib 0x387c1c8c thread_start + 4
Thread 8 name: com.apple.CFSocket.private
Thread 8:
0 libsystem_kernel.dylib 0x3875b440 __select + 20
1 CoreFoundation 0x2d98e680 __CFSocketManager + 480
2 libsystem_pthread.dylib 0x387c3c1a _pthread_body + 138
3 libsystem_pthread.dylib 0x387c3b8a _pthread_start + 98
4 libsystem_pthread.dylib 0x387c1c8c thread_start + 4
Thread 0 crashed with ARM Thread State (32-bit):
r0: 0x00000000 r1: 0x00000000 r2: 0x00000000 r3: 0x00002060
r4: 0x00000006 r5: 0x3a60618c r6: 0x00000000 r7: 0x27d80594
r8: 0x1451e760 r9: 0x00000001 r10: 0x00000000 r11: 0x403e0000
ip: 0x00000148 sp: 0x27d80588 lr: 0x387c4a33 pc: 0x3875b1fc
cpsr: 0x00000010
how could I get to the cause of this crash log, thanks
That Apple isn't providing the Binary Images section in the provided crash report makes it much harder than necessary to find out what the cause is. Without the that information it is not possible to symbolicate the Last Exception Backtrace and find out more automatically.
The reason for the crash is definitely an exception inside the app, it is not because the apps main thread was blocking for too long because in that case the report would not show a Last Exception Backtrace and look very different. But using synchronous networking requests on the main thread should never be done anyway!
So how to find out more about this exception. Since the Binary Images are missing and the symbols for the system calls are already symbolicated, it is hard to find the address ranges for each system framework. But we know the load address from the app looking at the following line:
13 taptap 0x0008fde2 0x83000 + 52706
So the load address is 0x83000. Now we take the Last Exception Backtrace addresses and search for the ones that are likely belonging to the app:
0x2d9bff46 0x3819c6aa 0x2d9bfe88 0x2e347a66 0x8c47c 0x2d982114 0x2d8f6252 0x2e2dbc28 0x301b1f52
0x3019d4c4 0x3013841a 0x3013771c 0x3019cb38 0x325d5708 0x325d52f2 0x2d98a9da 0x2d98a976 0x2d98914a
0x2d8f3c22 0x2d8f3a06 0x3019bdd4 0x30197044 0x8fde2 0x386a4ab2
The ones that should belong to the app are the following:
0x8c47c 0x8fde2
0x8fde2 is the same as in the main thread and will symbolicate to something like
13 taptap 0x0008fde2 main (main.m:14)
The interesting one is 0x8c47c, which shows up 5th place from top from the exception. To get the symbol for this one, you need the apps dSYM that you submitted to Apple. You'll find it in the organizer Archives tab. Select the app and choose the entry for the app. Right mouse click the item that you used to submit to Apple and choose Show in Finder. Then another right mouse click and choose Show Package Contents. Open the dSYMs folder.
It is unknown which iPad was used and since the Binary Images section is missing we don't know it either (which would show the used architecture and UUID to verify the architecture, binary, and dSYM). So it can be either armv7 or armv7s. The newest iPad mini with retina and the iPad Air use armv7s in 32 bit mode, all other iPads also either use armv7s or armv7. So we have to try both which may return the same results.
Now open a terminal window and type:
`xcrun atos -arch armv7s -l 0x83000 DragInTheDSYMItemFromTheFinderInHere 0x8c47c`
Then use the same if it doesn't make sense and replace armv7s with armv7.
This should give you the class, method, filename and line number where the exception occured in your app. We'll still be missing the exception reason since the crash report doesn't show that and due to missing binary images we can't really symbolicate all the other addresses and use that find out more. Hopefully this will already give an idea.
Once you have that, please update your question with the details.
UPDATE: Now that the binary images where provided, I was able to symbolicate the crash report and get the Last Exception Backtrace symbols. Although without the app symbols, since I obviously don't have the dSYM.
The symbolicated report is available here: http://pastebin.com/An10dUpi
The important frames are the following
Last Exception Backtrace:
0 CoreFoundation 0x2d9bff46 __exceptionPreprocess + 126
1 libobjc.A.dylib 0x3819c6aa objc_exception_throw + 32
2 CoreFoundation 0x2d9bfe88 +[NSException raise:format:] + 98
3 Foundation 0x2e347a66 +[NSJSONSerialization JSONObjectWithData:options:error:] + 60
4 taptap 0x8c47c 0x83000 + 38012
This shows that the crash occurs because the app tries to serialize a given NSData object into json and fails to do so, because the NSData object is not a valid json string.
When symbolicating the 4th line as described above in the post, you will get the exact line in your code where this happens.
I have a problem in my app. My app is using internet connection. When I run it in the device from the Xcode its running without crashing. But when I install it fisttime it runs, but if I close the app and then try to again run after loading the splash screen it crashes. Why is that? But this is working when I'm run the app through the xcode in the device.
But when I use 3G instead of wifi it goes beyond the splash screen
Updated
Incident Identifier: 5AAF8220-55D5-4011-B14A-F9A86C624F7C
CrashReporter Key: f0828a82293c0951598f3501da6c4cc391e66276
Hardware Model: iPad1,1
Process: mMusic [303]
Path: /var/mobile/Applications/6D985396-5C2A-430D-B605-617EFA46A470/mMusic.app/mMusic
Identifier: mMusic
Version: ??? (???)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2013-09-25 10:11:07.842 +0530
OS Version: iPhone OS 5.1.1 (9B206)
Report Version: 104
Exception Type: 00000020
Exception Codes: 0x8badf00d
Highlighted Thread: 0
Application Specific Information:
com.microimage.mMusic failed to launch in time
Elapsed total CPU time (seconds): 1.050 (user 1.050, system 0.000), 5% CPU
Elapsed application CPU time (seconds): 0.237, 1% CPU
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0:
0 libsystem_kernel.dylib 0x357fb004 mach_msg_trap + 20
1 libsystem_kernel.dylib 0x357fb1fa mach_msg + 50
2 CoreFoundation 0x357693ec __CFRunLoopServiceMachPort + 120
3 CoreFoundation 0x35768124 __CFRunLoopRun + 876
4 CoreFoundation 0x356eb49e CFRunLoopRunSpecific + 294
5 CoreFoundation 0x356eb366 CFRunLoopRunInMode + 98
6 CFNetwork 0x314ade14 CFURLConnectionSendSynchronousRequest + 340
7 Foundation 0x34b304a6 +[NSURLConnection sendSynchronousRequest:returningResponse:error:] + 242
8 Foundation 0x34b54356 -[NSData(NSData) initWithContentsOfURL:] + 178
9 Foundation 0x34b85174 +[NSData(NSData) dataWithContentsOfURL:] + 36
10 mMusic 0x0013b2a4 0xa5000 + 615076
11 mMusic 0x0012fc34 0xa5000 + 568372
12 mMusic 0x000a6b96 0xa5000 + 7062
13 UIKit 0x32ecdca4 -[UIApplication _callInitializationDelegatesForURL:payload:suspended:] + 1176
14 UIKit 0x32ec77d6 -[UIApplication _runWithURL:payload:launchOrientation:statusBarStyle:statusBarHidden:] + 402
15 UIKit 0x32e95abc -[UIApplication handleEvent:withNewEvent:] + 1004
16 UIKit 0x32e95560 -[UIApplication sendEvent:] + 48
17 UIKit 0x32e94f34 _UIApplicationHandleEvent + 5820
18 GraphicsServices 0x33487224 PurpleEventCallback + 876
19 CoreFoundation 0x3576951c __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 32
20 CoreFoundation 0x357694be __CFRunLoopDoSource1 + 134
21 CoreFoundation 0x3576830c __CFRunLoopRun + 1364
22 CoreFoundation 0x356eb49e CFRunLoopRunSpecific + 294
23 CoreFoundation 0x356eb366 CFRunLoopRunInMode + 98
24 UIKit 0x32ec6864 -[UIApplication _run] + 544
25 UIKit 0x32ec3cce UIApplicationMain + 1074
26 mMusic 0x000a638c 0xa5000 + 5004
27 mMusic 0x000a62e8 0xa5000 + 4840
Thread 1 name: Dispatch queue: com.apple.libdispatch-manager
Thread 1:
0 libsystem_kernel.dylib 0x357fb3a8 kevent + 24
1 libdispatch.dylib 0x33b2eea4 _dispatch_mgr_invoke + 708
2 libdispatch.dylib 0x33b2ebc2 _dispatch_mgr_thread + 30
Thread 2 name: WebThread
Thread 2:
0 libsystem_kernel.dylib 0x357fb004 mach_msg_trap + 20
1 libsystem_kernel.dylib 0x357fb1fa mach_msg + 50
2 CoreFoundation 0x357693ec __CFRunLoopServiceMachPort + 120
3 CoreFoundation 0x35768124 __CFRunLoopRun + 876
4 CoreFoundation 0x356eb49e CFRunLoopRunSpecific + 294
5 CoreFoundation 0x356eb366 CFRunLoopRunInMode + 98
6 WebCore 0x37431c9c _ZL12RunWebThreadPv + 396
7 libsystem_c.dylib 0x349b472e _pthread_start + 314
8 libsystem_c.dylib 0x349b45e8 thread_start + 0
Thread 3 name: com.apple.NSURLConnectionLoader
Thread 3:
0 libsystem_kernel.dylib 0x357fb004 mach_msg_trap + 20
1 libsystem_kernel.dylib 0x357fb1fa mach_msg + 50
2 CoreFoundation 0x357693ec __CFRunLoopServiceMachPort + 120
3 CoreFoundation 0x35768124 __CFRunLoopRun + 876
4 CoreFoundation 0x356eb49e CFRunLoopRunSpecific + 294
5 CoreFoundation 0x356eb366 CFRunLoopRunInMode + 98
6 Foundation 0x34b30bb2 +[NSURLConnection(Loader) _resourceLoadLoop:] + 302
7 Foundation 0x34b30a7a -[NSThread main] + 66
8 Foundation 0x34bc458a __NSThread__main__ + 1042
9 libsystem_c.dylib 0x349b472e _pthread_start + 314
10 libsystem_c.dylib 0x349b45e8 thread_start + 0
Thread 4 name: com.apple.CFSocket.private
Thread 4:
0 libsystem_kernel.dylib 0x3580b570 __select + 20
1 CoreFoundation 0x3576d63a __CFSocketManager + 726
2 libsystem_c.dylib 0x349b472e _pthread_start + 314
3 libsystem_c.dylib 0x349b45e8 thread_start + 0
Unknown thread crashed with unknown flavor: 5, state_count: 1
Looks like your application was killed by the Springboard because it failed to launch before the watchdog timer expired.
Exception Codes: 0x8badf00d
Application Specific Information:
com.microimage.mMusic failed to launch in time
It looks like you are making a synchronous call to download data at application launch. This is blocking the main thread causing application to not launch in time. You should allow the application to launch completely first and then initiate the network call on background thread (not the main thread).
Read more from these links: Link1, Link2
The exception code 0x8badf00d indicates that an application has been terminated by iOS because a watchdog timeout occurred. The application took too long to launch, terminate, or respond to system events. One common cause of this is doing synchronous networking on the main thread. Whatever operation is on Thread 0: needs to be moved to a background thread, or processed differently, so that it does not block the main thread.
Hope that helps!
If you get Exception Type: 00000020 and Exception Codes: 0x8badf00d in your crash log then it is due to running synchronous task on main thread. Solution is to use asynchronous task on main thread.
It is referred to as watchdog timeout crash reports. You can check this Apple document for details.
Seeing a similar crash for our watchos 3 app.
Part of the problem was it was difficult to get a complete crash report. Only when I was able to reliably reproduce the crash and repeated it 20-30 times did I get a single coherent crash report with a stack trace. Saw many partial reports with some json including kernel, crashReporterKey, memoryPages etc. but only one complete report with a stack trace.
Another problem, xcode never connected to the device while debugging. Of course, the app was killed for taking to long to start, so the debugger is of no use. Same symptoms with simulator.
Solution: we were activating our wcsession in our extension delegate's applicationDidFinishLaunching. Activation is asynchronous, so I assumed this was ok. Moving session activation to applicationDidBecomeActive have fixed the issue.
I am done with development process of the app, before releasing it to app store i had done several rounds of testing (Adhoc testing on IOS version 6.0.1). while doing Adhoc testing i didnt find any issues with the build. Everything was working fine. After submitting to app store i got the report from apple team saying that application is crashing on iphone 5 having IOS version 6.1.3. So i updated my iphone to 6.1.3 . After updating to latest version, i uploaded the build to testflight and downloaded the app from it. it was crashing. i uninstalled the app from phone and directly connected to system and installed directly through xcode with out any code changes. App started working fine. I am confused with reason behind crashing. I am certain it is not an issue with the code because same code is working fine if i directly install through xcode.
whats the difference b/w installing app through testflight and directly from xcode ?
What might be the problem ?
i symbolicated the crash logs and found nothing wrong with code.
does anyone has faced similar kind of problem ? if got fixed plz help me out. your help is highly admired. Thanks
below is my crash log
Version: ??? (???)
Code Type: `enter code here`ARM (Native)
Parent Process: launchd `enter code here`[1]
Date/Time: 2013-05-07 10:19:43.206 -0700
OS Version: iOS 6.1.4 (10B350)
Report Version: 104
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x43462d40
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libobjc.A.dylib 0x3bc905d0 objc_msgSend + 16
1 Foundation 0x348031dc _NSDescriptionWithLocaleFunc + 48
2 CoreFoundation 0x33f7b42e __CFStringAppendFormatCore + 11158
3 CoreFoundation 0x33ef289e _CFStringCreateWithFormatAndArgumentsAux +
4 Foundation 0x34802cf8 +[NSString stringWithFormat:] + 56
5 Nuedoo 0x0002f8a2 -[VCache updateWithXML:] (VCache.m:122)
6 Nuedoo 0x0003f00a -[VParser parseXMLFile:] (VParser.m:80)
7 Nuedoo 0x0002ecda -[VBrowser open:] (VBrowser.m:23)
8 Nuedoo 0x0002d6e8 -[Vaayoo_FrameworkAppDelegate:] (Vaayoo_FrameworkAppDelegate.m:57)
9 UIKit 0x35e09a9c -[UIApplication _handleDelegateCallbacksWithOptions:isSuspended:restoreState:] + 248
10 UIKit 0x35e09620 -[UIApplication _callInitializationDelegatesForURL:payload:suspended:] + 1164
11 UIKit 0x35e0182e -[UIApplication _runWithURL:payload:launchOrientation:statusBarStyle:statusBarHidden:] + 694
12 UIKit 0x35da9d1a -[UIApplication handleEvent:withNewEvent:] + 1006
13 UIKit 0x35da97a8 -[UIApplication sendEvent:] + 68
14 UIKit 0x35da91ea _UIApplicationHandleEvent + 6194
15 GraphicsServices 0x37ac15f4 _PurpleEventCallback + 588
16 GraphicsServices 0x37ac1222 PurpleEventCallback + 30
17 CoreFoundation 0x33f6f3e4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 32
18 CoreFoundation 0x33f6f386 __CFRunLoopDoSource1 + 134
19 CoreFoundation 0x33f6e20a __CFRunLoopRun + 1378
20 CoreFoundation 0x33ee1238 CFRunLoopRunSpecific + 352
21 CoreFoundation 0x33ee10c4 CFRunLoopRunInMode + 100
22 UIKit 0x35e00468 -[UIApplication _run] + 664
23 UIKit 0x35dfd2b4 UIApplicationMain + 1116
24 Nuedoo 0x00056efa main (main.m:14)
25 Nuedoo 0x0002ce84 start + 36
Thread 1:
0 libsystem_kernel.dylib 0x3c189d98 __workq_kernreturn + 8
1 libsystem_c.dylib 0x3c0d7ad6 _pthread_workq_return + 14
2 libsystem_c.dylib 0x3c0d77f2 _pthread_wqthread + 362
3 libsystem_c.dylib 0x3c0d7680 start_wqthread + 4
Thread 2 name: Dispatch queue: com.apple.libdispatch-manager
Thread 2:
0 libsystem_kernel.dylib 0x3c1795d0 kevent64 + 24
1 libdispatch.dylib 0x3c0b4d22 _dispatch_mgr_invoke + 806
2 libdispatch.dylib 0x3c0b0374 _dispatch_mgr_thread + 32
Thread 3:
0 libsystem_kernel.dylib 0x3c189d98 __workq_kernreturn + 8
1 libsystem_c.dylib 0x3c0d7ad6 _pthread_workq_return + 14
2 libsystem_c.dylib 0x3c0d77f2 _pthread_wqthread + 362
3 libsystem_c.dylib 0x3c0d7680 start_wqthread + 4
Thread 4 name: WebThread
Thread 4:
0 libsystem_kernel.dylib 0x3c178e30 mach_msg_trap + 20
1 libsystem_kernel.dylib 0x3c178fd0 mach_msg + 48
2 CoreFoundation 0x33f6f2b6 __CFRunLoopServiceMachPort + 126
3 CoreFoundation 0x33f6e02c __CFRunLoopRun + 900
4 CoreFoundation 0x33ee1238 CFRunLoopRunSpecific + 352
5 CoreFoundation 0x33ee10c4 CFRunLoopRunInMode + 100
6 WebCore 0x39ee9390 RunWebThread(void*) + 440
7 libsystem_c.dylib 0x3c0e20de _pthread_start + 306
8 libsystem_c.dylib 0x3c0e1fa4 thread_start + 4
Thread 0 crashed with ARM Thread State (32-bit):
r0: 0x1f5c0ab0 r1: 0x39a512ae r2: 0x34004b3a r3: 0xffffffff
r4: 0x43462d38 r5: 0x00000000 r6: 0x34004b3a r7: 0x2fdd3178
r8: 0x2fdd367c r9: 0x0e6944ab r10: 0x3c307c20 r11: 0x1f5c0ca0
ip: 0x3c3b8704 sp: 0x2fdd3164 lr: 0x348031e1 pc: 0x3bc905d0
cpsr: 0x20000030
</string>
<key>displayName</key>
<string>Nuedoo</string>
<key>name</key>
<string>Nuedoo</string>
<key>os_version</key>
<string>iPhone OS 6.1.4 (10B350)</string>
<key>system_ID</key>
<string></string>
<key>version</key>
<string>??? (???)</string>
</dict>
</plist>
Installing the app directly through XCode will use your 'Debug' configuration (depends also on how it's set in your build scheme). Archiving it first, will use your Adhoc/Release configuration.
The configurations may differ in search paths, constants, preprocessor macros and other things used during compile/build time.
Since it's working well when built directly from xcode, you may have a look at the differences between your Run build configuration ('Debug') and your 'Archive' build configuration ('Adhoc' in the image above).
To view differences between your configurations, select your app target and search for the fields with <Multiple values> (inside Build Settings tab)
You may also be able to set your 'Run' step to use the 'Release' configuration (with a correct provisioning that accepts your device), in which case you should be able to catch the exception when connected to xcode (and maybe have a better look at what's causing it using breakpoints).
KERN_INVALID_ADDRESS is ether a bad cast or a zombie object. If it was a bad cast it should crash in debug as well as release. The debugger can hide some memory errors. The good news it the crash in repeatable in the release build. You just need to profile your app in Instruments
using the Zombie Instrument.
Here is a good tutorial:
http://www.dimzzy.com/blog/2011/02/hunting-down-zombies-in-ios-apps/