I already have this app on app store. I released an updated version with some changes. This app is using CoreData for data persistence. I have tested its new version before releasing it on app store, it was working as required. But after submitting on app store and updating it from there the app is crashing after each launch. I have that crash report, but it doesn't make any sense to me. I didn't change anything in CoreData.
After launch, this app is showing a UITableView and this tableView is getting data from CoreData.
Here is the crash report.
Incident Identifier: 7A9713FF-40CB-45E0-961F-F4D1B003F2B5
CrashReporter Key: 891c38a57639ab8e2bcc3012687292ce9aa818f5
Hardware Model: iPhone6,2
Process: APPName [7461]
Path: /var/mobile/Applications/A9028B70-0878-40FA-944B-584B15E49B69/APPName.app/APPName
Identifier: co.identifier.app
Version: 2.5 (2.5)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2014-03-13 09:39:17.309 +0000
OS Version: iOS 7.0.6 (11B651)
Report Version: 104
Exception Type: 00000020
Exception Codes: 0x000000008badf00d
Highlighted Thread: 0
Application Specific Information:
co.identifier.app failed to launch in time
Elapsed total CPU time (seconds): 1.660 (user 1.660, system 0.000), 4% CPU
Elapsed application CPU time (seconds): 0.304, 1% CPU
Thread 0:
0 libsystem_kernel.dylib 0x3a161fa8 __psynch_mutexwait + 24
1 libsystem_pthread.dylib 0x3a1c6f4d _pthread_mutex_lock + 305
2 CoreData 0x2f595a91 -[_PFLock lock] + 21
3 CoreData 0x2f5a6b35 -[NSPersistentStoreCoordinator executeRequest:withContext:error:] + 777
4 CoreData 0x2f5a5777 -[NSManagedObjectContext executeFetchRequest:error:] + 611
5 APPName 0x000ecc11 +[DataManager dataEntryEntity:] (DataManager.m:385)
6 APPName 0x000ebca9 +[DataManager dataForDateKey:] (DataManager.m:126)
7 APPName 0x000cff9d -[CalendarCell setDateKey:] (CalendarCell.m:820)
8 APPName 0x000bd969 -[CalendarViewController tableView:cellForRowAtIndexPath:] (CalendarViewController.m:832)
9 UIKit 0x32108311 -[UITableView _createPreparedCellForGlobalRow:withIndexPath:] + 405
10 UIKit 0x320b06c9 -[UITableView _updateVisibleCellsNow:] + 1797
11 UIKit 0x320afeed -[UITableView layoutSubviews] + 181
12 UIKit 0x31fd634f -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 343
13 QuartzCore 0x31c5c93f -[CALayer layoutSublayers] + 139
14 QuartzCore 0x31c58163 CA::Layer::layout_if_needed(CA::Transaction*) + 347
15 QuartzCore 0x31c57ff5 CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 13
16 QuartzCore 0x31c57a09 CA::Context::commit_transaction(CA::Transaction*) + 225
17 QuartzCore 0x31c5781b CA::Transaction::commit() + 311
18 UIKit 0x32055a37 -[UIApplication _reportAppLaunchFinished] + 39
19 UIKit 0x32040edb -[UIApplication _runWithURL:payload:launchOrientation:statusBarStyle:statusBarHidden:] + 1643
20 UIKit 0x31fdba03 -[UIApplication handleEvent:withNewEvent:] + 3139
21 UIKit 0x31fdacf9 -[UIApplication sendEvent:] + 69
22 UIKit 0x3204031d _UIApplicationHandleEvent + 661
23 GraphicsServices 0x344ba76b _PurpleEventCallback + 607
24 GraphicsServices 0x344ba353 PurpleEventCallback + 31
25 CoreFoundation 0x2f81c775 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 33
26 CoreFoundation 0x2f81c70f __CFRunLoopDoSource1 + 343
27 CoreFoundation 0x2f81aedb __CFRunLoopRun + 1403
28 CoreFoundation 0x2f78546d CFRunLoopRunSpecific + 521
29 CoreFoundation 0x2f78524f CFRunLoopRunInMode + 103
30 UIKit 0x3203f5bf -[UIApplication _run] + 759
31 UIKit 0x3203a841 UIApplicationMain + 1133
32 APPName 0x000b6ba7 main (main.m:11)
33 libdyld.dylib 0x3a0abab5 start + 1
This crash is producing on every device which updates the app and this is not reproducing in simulator testing or in testing build through testFlight distribution.
As Phillip stated in the comment, the reason for this crash is due to the watchdog.
If your app is stuck in the method -applicationDidFinishLauchingWithOptions: for a long time, the system kills it.
The reason is that probably you are doing an expensive time task on the main thread inside this method, that could be a migration, copying or deleting a lot of files.
You never experienced in your tests because probably you used small amount of data or because in debug mode the watchdog isn't active (not sure about it).
Unfortunately I think that you should release another version as soon as possible to fix that, the solution could be launch those long running task on a background thread.
To prevent those problems always to try updating an old app using ad-hoc distribution before releasing it.
From http://www.raywenderlich.com/23704/demystifying-ios-application-crash-logs
Here are some of the more common exception codes:
0x8badf00d: Reads as “ate bad food”! (If you squint your eyes and replace the digits with alphabetic characters. :p) This code indicates that an application was terminated by iOS because a watchdog timeout occurred. Basically, the application took too long to launch, terminate, or respond to system events.
The crash is because of a long wait, what's causing it is in 1 of 321 task items listed in the log.
I am really curious about your send event / handle event items in the log. Is there any chance that you are waiting for something before launching the rootViewController? ... it could be core data but if there is something very wrong I sort of expected another error to happen instead of along wait.
Related
My app was rejected with this reason:
Your app crashed on iPad running iOS 13.4.1 on WiFi when we:
Tapped on any locked content
Tapped on the settings icon
We have attached detailed crash logs to help troubleshoot this issue.
I tested my app. Everything work fine. How can I find the error?
One of three crashlogs:
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x000000010403514c
Termination Signal: Trace/BPT trap: 5
Termination Reason: Namespace SIGNAL, Code 0x5
Terminating Process: exc handler [630]
Triggered by Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 appTime 0x000000010403514c 0x104014000 + 135500
1 appTime 0x00000001040351b8 0x104014000 + 135608
2 UIKitCore 0x00000001acfece08 -[UIViewController _sendViewDidLoadWithAppearanceProxyObjectTaggingEnabled] + 100
3 UIKitCore 0x00000001acff1898 -[UIViewController loadViewIfRequired] + 936
4 UIKitCore 0x00000001acff1ca0 -[UIViewController view] + 28
5 UIKitCore 0x00000001acf1cccc -[_UIFullscreenPresentationController _setPresentedViewController:] + 80
6 UIKitCore 0x00000001acf10810 -[UIPresentationController initWithPresentedViewController:presentingViewController:] + 188
7 UIKitCore 0x00000001ad0014bc -[UIViewController _presentViewController:withAnimationController:completion:] + 2616
8 UIKitCore 0x00000001ad004014 __63-[UIViewController _presentViewController:animated:completion:]_block_invoke + 104
9 UIKitCore 0x00000001ad00451c -[UIViewController _performCoordinatedPresentOrDismiss:animated:] + 508
10 UIKitCore 0x00000001ad003f64 -[UIViewController _presentViewController:animated:completion:] + 196
11 UIKitCore 0x00000001ad0041d0 -[UIViewController presentViewController:animated:completion:] + 164
12 UIKitCore 0x00000001ad791db0 __67-[UIStoryboardModalSegueTemplate newDefaultPerformHandlerForSegue:]_block_invoke + 248
13 UIKitCore 0x00000001ad796ac4 -[UIStoryboardSegueTemplate _performWithDestinationViewController:sender:] + 292
14 UIKitCore 0x00000001ad796970 -[UIStoryboardSegueTemplate _perform:] + 92
15 UIKitCore 0x00000001acff43b0 -[UIViewController performSegueWithIdentifier:sender:] + 104
16 appTime 0x0000000104023c44 0x104014000 + 64580
17 appTime 0x0000000104023338 0x104014000 + 62264
18 UIKitCore 0x00000001ad80bb4c -[UITableView _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:isCellMultiSelect:] + 1200
19 UIKitCore 0x00000001ad80b684 -[UITableView _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:] + 108
20 UIKitCore 0x00000001ad80be8c -[UITableView _userSelectRowAtPendingSelectionIndexPath:] + 268
21 UIKitCore 0x00000001ad63b94c _runAfterCACommitDeferredBlocks + 316
22 UIKitCore 0x00000001ad62b2f4 _cleanUpAfterCAFlushAndRunDeferredBlocks + 232
23 UIKitCore 0x00000001ad65b744 _afterCACommitHandler + 76
24 CoreFoundation 0x00000001a9504fb8 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 32
25 CoreFoundation 0x00000001a94ffeac __CFRunLoopDoObservers + 420
26 CoreFoundation 0x00000001a9500328 __CFRunLoopRun + 968
27 CoreFoundation 0x00000001a94ffc34 CFRunLoopRunSpecific + 424
28 GraphicsServices 0x00000001b364938c GSEventRunModal + 160
29 UIKitCore 0x00000001ad63222c UIApplicationMain + 1932
30 appTime 0x000000010401b3ec 0x104014000 + 29676
31 libdyld.dylib 0x00000001a9387800 start + 4
Short answer, you use the crashlog to identify the part of code where the app crashed, and be effective with writing a fix.
Now the long answer:
Refer to the Technical Note TN2151 - Understanding and Analyzing Application Crash Reports on Apple Developer website.
When an application crashes, a crash report is created and stored on the device. Crash reports describe the conditions under which the application terminated, in most cases including a complete backtrace for each executing thread, and are typically very useful for debugging issues in the application. You should look at these crash reports to understand what crashes your application is having, and then try to fix them.
and
Crash reports with backtraces need to be symbolicated before they can be analyzed. Symbolication replaces memory addresses with human-readable function names and line numbers. If you get crash logs off a device through Xcode's Devices window, then they will be symbolicated for you automatically after a few seconds. Otherwise you will need to symbolicate the .crash file yourself by importing it to the Xcode Devices window. See Symbolicating Crash Reports for details.
So to put it simply, when you build your app with Xcode, the compiler also generates debug symbols. You should generally store the debug symbols in a dSYM file corresponding to the build that you submit for review.
If your app crashes during review, the App Store Review team member fetches and shares the crash log with you. Now the crash log contains machine (assembly language) instructions, and your can use Xcode to symbolicate the crash report. Doing this would convert the machine symbols into the name of identifies that you have in your code, which would help you with determining the section of code where the crash occurred.
Consider reading the attached technical note to understand how you can easily determine the part of code where your app crashed and be more effective with fix.
I've been dealing with a pernicious crash bug in my iPhone app, which is consistently reproducible in the version downloaded from the App Store, but not at all in the debug version. I have produced a workaround, which works by excluding the critical drawing code from running during a UIViewController animation.
The crash log indicates that there is an assert failure in CGPathAddLineToPoint.
The app uses the drawing functions CGContextMoveToPoint, CGContextAddLineToPoint, and CGContextStrokePath. The functions CGPathCreateMutable, CGPathAddLines, and CGContextAddPath are also used, but the app still crashes even in configurations that (should) avoid invoking them.
The crash happens consistently when lines are drawn on a view while its UIViewController is being presented (animated). Otherwise, the drawing works without issue.
I have confirmed in the debug version that every point of every line drawn is real and within the boundaries of the view.
The app crashes immediately on iOS7 when the drawing is attempted. On iOS5 and iOS6, the app stops responding for 30 seconds before crashing, leaving behind an "Unknown" crash log with no information.
The only cases I could find on the web similar to this problem were CGFloatIsValid assert failures in CGPathAddLineToPoint in OS X apps (including iPhoto crash logs posted to Apple's support forums).
I can't say much more about it because the app never crashes or even gives a warning in the debug version. Has anyone else encountered this bug? Is there a better way to resolve this issue?
You can view the workaround in action in the release version on the App Store. You can see that the line drawing on the graph is delayed until after the animation completes when you push the [Graph] button, when the calculator is in 2D mode.
The important part of the crash log (from an iPhone 5S running iOS 7.0.3, app armv7):
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Triggered by Thread: 0
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x3a5e11fc __pthread_kill + 8
1 libsystem_pthread.dylib 0x3a648a4f pthread_kill + 55
2 libsystem_c.dylib 0x3a592029 abort + 73
3 libsystem_c.dylib 0x3a571c67 __assert_rtn + 179
4 CoreGraphics 0x2fd566f5 CGPathAddLineToPoint + 149
5 (My App) 0x001464cd 0xd7000 + 455885
6 UIKit 0x324d4dd5 -[UIView(CALayerDelegate) drawLayer:inContext:] + 369
7 QuartzCore 0x3210aa75 -[CALayer drawInContext:] + 97
8 QuartzCore 0x320f4241 CABackingStoreUpdate_ + 1857
9 QuartzCore 0x321ce2e9 ___ZN2CA5Layer8display_Ev_block_invoke + 49
10 QuartzCore 0x320f3af1 x_blame_allocations + 81
11 QuartzCore 0x320f37a3 CA::Layer::display_() + 1115
12 QuartzCore 0x320d7365 CA::Layer::display_if_needed(CA::Transaction*) + 205
13 QuartzCore 0x320d6ffd CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 21
14 QuartzCore 0x320d6a09 CA::Context::commit_transaction(CA::Transaction*) + 225
15 QuartzCore 0x320d681b CA::Transaction::commit() + 311
16 QuartzCore 0x320d0549 CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*) + 53
17 CoreFoundation 0x2fc9bf67 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 19
18 CoreFoundation 0x2fc998f3 __CFRunLoopDoObservers + 283
19 CoreFoundation 0x2fc99c3f __CFRunLoopRun + 735
20 CoreFoundation 0x2fc0446d CFRunLoopRunSpecific + 521
21 CoreFoundation 0x2fc0424f CFRunLoopRunInMode + 103
22 GraphicsServices 0x349382e7 GSEventRunModal + 135
23 UIKit 0x324b9841 UIApplicationMain + 1133
24 (My App) 0x000de723 0xd7000 + 30499
25 (My App) 0x000dde0c 0xd7000 + 28172
Several things:
Try opening the crash log on the machine from which you submitted the version in the app store. That version should have the archive containing the symbol file that you need to symbolicate the crash log.
If you only crash when you add lines to a path while your view controller is being animated onto the screen, why not add code to the completion block of your call to presentViewController:animated:completion: that invokes a method enabling drawing. Set up your view controller so drawing is disabled when it's first displayed, and gets enabled by the method call in the completion block.
To clarify (for people of the future), there is a workaround if your app is crashing during an animation, only in the App Store version, and the crash logs indicate an assert failure in CGPathAddLineToPoint. Just exclude all line-drawing code from running during the animation, and it won't crash.
In one of our iPhone apps, we have gotten a few Crashlytics crashes that we have, so far, been unable to reproduce. However, on closer inspection, I noticed a bit of a trend...
Crash 1: -[UINavigationTransitionView _notifyDelegateTransitionDidStopWithContext:]
Free RAM: 10%
Crash 2: -[UINavigationTransitionView _notifyDelegateTransitionDidStopWithContext:]
Free RAM: 8%
Crash 3: HostBase::lock()
Free RAM: 8%
Crash 4:-[UINavigationTransitionView _notifyDelegateTransitionDidStopWithContext:]
Free RAM: 22%
Does the amount of free RAM mean anything? Can we be sure that these are actual crashes and not our app getting killed by the OS due to low memory? Does Crashlytics send crash reports if the app crashes while in the background?
Added a couple stack traces...
Exception Type: SIGSEGV, Nav Crashes
0 libobjc.A.dylib
objc_msgSend + 15
1 UIKit ✭
-[UINavigationTransitionView _notifyDelegateTransitionDidStopWithContext:] + 274
2 UIKit
-[UIViewAnimationState sendDelegateAnimationDidStop:finished:] + 158
3 UIKit
-[UIViewAnimationState animationDidStop:finished:] + 50
4 QuartzCore
CA::Layer::run_animation_callbacks(void*) + 208
5 libdispatch.dylib
_dispatch_client_callout + 22
6 libdispatch.dylib
_dispatch_main_queue_callback_4CF$VARIANT$mp + 224
7 CoreFoundation
__CFRunLoopRun + 1290
8 CoreFoundation
CFRunLoopRunSpecific + 356
9 CoreFoundation
CFRunLoopRunInMode + 104
10 GraphicsServices
GSEventRunModal + 74
11 UIKit
UIApplicationMain + 1120
Exception Type: SIGSEGV, HostLock crash
0 libobjc.A.dylib
objc_msgSend + 15
1 CFNetwork ✭
HostBase::lock() + 14
2 CFNetwork
DispatchHost::performInvocation(void const*) + 12
3 CFNetwork
__setupTCPConnection_block_invoke_2 + 290
4
...
libsystem_network.dylib
__tcp_connection_notify_complete_block_invoke_1 + 18
7 libsystem_c.dylib
_pthread_wqthread + 294
8% memory can be a lot, I highly doubt that this is an issue. I don't know if they send crashes while running in the background, you have to ask them directly since their SDK is not open source.
Both exception stack traces you added hint at a memory problem.
The first one looks like it tries to call a delegate at the end of an animation of an object, which does not exist any more.
The second one looks like a similar problem, where the completion block is accessing an object that is gone. So you might check your blocks for such patterns.
My application is crashing when one of the views is purged from memory because of low-memory condition. At least this is what I understand from the crashlog. It happens on numerous screens but only when opening a Facebook dialog (using the Facebook SDK). Basically, looks like the system sometimes runs out of memory when we need to present a Facebook dialog (e.g. to let user post something on the Facebook timeline).
Date/Time: 2012-03-14 19:47:33.819 +0000
OS Version: iPhone OS 5.1 (9B176)
Report Version: 104
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x30000008
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libobjc.A.dylib 0x30f2bf78 objc_msgSend + 16
1 MyApp 0x00003c0e -LTBaseViewController viewDidUnload (LTBaseViewController.m:145)
2 MyApp 0x00004ea2 -LTBaseTableViewController viewDidUnload (LTBaseTableViewController.m:90)
3 UIKit 0x33766bd8 -[UIViewController unloadViewForced:] + 244
4 UIKit 0x338ae492 -[UIViewController purgeMemoryForReason:] + 58
5 Foundation 0x3071a4f8 __57-NSNotificationCenter addObserver:selector:name:object:_block_invoke_0 + 12
6 CoreFoundation 0x30e95540 ___CFXNotificationPost_block_invoke_0 + 64
7 CoreFoundation 0x30e21090 _CFXNotificationPost + 1400
8 Foundation 0x3068e3e4 -NSNotificationCenter postNotificationName:object:userInfo: + 60
9 Foundation 0x3068fc14 -NSNotificationCenter postNotificationName:object: + 24
10 UIKit 0x3387926a -UIApplication _performMemoryWarning + 74
11 UIKit 0x33879364 -UIApplication _receivedMemoryNotification + 168
12 libdispatch.dylib 0x36a12252 _dispatch_source_invoke + 510
13 libdispatch.dylib 0x36a0fb1e _dispatch_queue_invoke$VARIANT$up + 42
14 libdispatch.dylib 0x36a0fe64 _dispatch_main_queue_callback_4CF$VARIANT$up + 152
15 CoreFoundation 0x30e9c2a6 __CFRunLoopRun + 1262
16 CoreFoundation 0x30e1f49e CFRunLoopRunSpecific + 294
17 CoreFoundation 0x30e1f366 CFRunLoopRunInMode + 98
18 GraphicsServices 0x33fb6432 GSEventRunModal + 130
19 UIKit 0x336f5e76 UIApplicationMain + 1074
20 MyApp 0x00004818 main (main.m:16)
21 MyApp 0x000023b4 0x1000 + 5044
I checked and there are almost no memory leaks, e.g. when testing the app for an hour the total memory leaked was around 2-3Kb caused by some string-copying libraries. So I don't believe this is caused by the application. I guess that when the phone is not restarted for some time there are applications running in the background and when using Facebook SDK the memory becomes a problem and the system tries to recover the memory from random applications, including my application.
My question is, how can I prevent this crash from happening? How should I handle unloadViewForced on a view controller to make the app more robust in low-memory conditions? And lastly, am I right that this crashlog suggests the crash occurred because the system tried to free memory and my application didn't handle it properly?
Any help greatly appreciated.
What is most likely happening is that one of the objects being referred to and probably being released by LTBaseViewController viewDidUnload method is being doubly released. In fact, since the backtrace indicates that the crash is happing on line 145 of LTBaseViewController.m you should be able to quickly see which object is the culprit.
An iPhone app is crashing on the device but not on the simulator. So I'm trying to learn how to interpret the crash log. I read lots of forum posts saying that the symbolicated crash log shows a back trace that gives the method and line number of the calls leading to the crash but I don't see anything useful. Maybe I'm not looking at the symbolicated crash log. Here is the beginning of what I see:
Incident Identifier: 432A8974-1661-409F-B5A6-970148550A46
CrashReporter Key: db93147c0a70a5f4c60dc92f826e72d5a74477c8
Hardware Model: iPhone3,3
Process: Darken [57959]
Path: /var/mobile/Applications/CB27C10F-CD3B-4148-8321-2C251888B27B/Darken.app/Darken
Identifier: Darken
Version: ??? (???)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2012-02-25 10:43:47.753 -0500
OS Version: iPhone OS 4.2.10 (8E600)
Report Version: 104
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000008
Crashed Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x32716464 objc_msgSend + 16
1 UIKit 0x3245e6fe -[UIScrollView(UIScrollViewInternal) _scrollViewAnimationEnded] + 90
2 CoreFoundation 0x32071bb8 -[NSObject(NSObject) performSelector:withObject:] + 16
3 UIKit 0x3245e5b8 -[UIAnimator stopAnimation:] + 276
4 UIKit 0x323efbf2 -[UIAnimator(Static) _advance:] + 214
5 UIKit 0x323efb0e LCDHeartbeatCallback + 10
6 GraphicsServices 0x35474362 HeartbeatVBLCallback + 86
7 IOMobileFramebuffer 0x34739bf4 IOMobileFramebufferVsyncNotifyFunc + 68
8 IOKit 0x348e5e64 IODispatchCalloutFromCFMessage + 192
9 CoreFoundation 0x32070be0 __CFMachPortPerform + 204
10 CoreFoundation 0x320686f8 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 20
11 CoreFoundation 0x320686bc __CFRunLoopDoSource1 + 160
12 CoreFoundation 0x3205af76 __CFRunLoopRun + 514
13 CoreFoundation 0x3205ac80 CFRunLoopRunSpecific + 224
14 CoreFoundation 0x3205ab88 CFRunLoopRunInMode + 52
15 GraphicsServices 0x354724a4 GSEventRunModal + 108
16 GraphicsServices 0x35472550 GSEventRun + 56
17 UIKit 0x323c7d1a -[UIApplication _run] + 406
18 UIKit 0x323c5884 UIApplicationMain + 664
19 Darken 0x000029d6 0x1000 + 6614
20 Darken 0x00002998 0x1000 + 6552
... Threads other than 0 listed here
Is anything here useful for finding out which line of my code led to the crash? Darken is the name of the application -- I already knew that. The only method name I recognize is UIApplicationMain but the crash didn't happen when the app was first launched -- I was running it about a minute and doing dozens of functions before the crash.
You may want to try and set NSZombieEnabled to YES in your project and let it crash with your device running in debug. It should stop at the line of code causing your crash. Your error looks like it is an EXC_BAD_ACCESS which usually means you were trying to access some deallocated memory.
You won't get a line number from a crash dump (unless you compiled your app with -g and run in GDB, but I doubt it since you don't seem to know what these are at all).
You ARE looking at the symbolicated crash dump: you DO have the names of the functions in the call stack. The crash occurs in the last called (topmost) function, which is objc_msgSend. That means you're not properly balancing your alloc/retain/copy methods with autorelease/release, and the messenger function tries to access already freed/corrupted/nonexistent memory, hence the crash (EXC_BAD_ACCESS is similar to a segfault, in fact you'll get one of these when you make such a mistake).
So my advice is, triple check your code for method calls modifying the reference count.