How to understand app rejection with crashlogs? - ios

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.

Related

Swift/iOS crash log does not contain line number

I'm deploying a build to testers via TestFlight and the app is crashing. I cannot reproduce the crash on my end so I am trying to rely on the crash logs listed in Xcode Organizer.
Unfortunately the crashes here contain some information, but nothing that allows me to identify the line of code that is causing the crash. Usually when I click on a crash in the Organizer window, it automatically shows me the line in Xcode that caused the crash.
Here's the raw crash log, which also does not contain a line number, only the file and method in which the crash occured.
Thread 0 name:
Thread 0 Crashed:
0 libswiftCore.dylib 0x0000000103154b8c 0x102f64000 + 2034572
1 libswiftCore.dylib 0x0000000103154b8c 0x102f64000 + 2034572
2 libswiftCore.dylib 0x000000010316017c 0x102f64000 + 2081148
3 libswiftCore.dylib 0x0000000103105cfc 0x102f64000 + 1711356
4 libswiftCore.dylib 0x0000000103160984 0x102f64000 + 2083204
5 libswiftCore.dylib 0x00000001030ad2f8 0x102f64000 + 1348344
6 AppName 0x0000000102c92748 specialized TableViewController.sendSmsMessage(sender:) + 8816 (TableViewController.swift:0)
(TableViewController.swift:0)
7 AppName 0x0000000102c8c448 #objc TableViewController.CorF(sender:) + 44
8 UIKitCore 0x00000001ea7a6314 -[UIApplication sendAction:to:from:forEvent:] + 96 (UIApplication.m:4786)
9 UIKitCore 0x00000001ea233d54 -[UIControl sendAction:to:forEvent:] + 80 (UIControl.m:624)
10 UIKitCore 0x00000001ea234074 -[UIControl _sendActionsForEvents:withEvent:] + 440 (UIControl.m:707)
11 UIKitCore 0x00000001ea233074 -[UIControl touchesEnded:withEvent:] + 568 (UIControl.m:461)
12 UIKitCore 0x00000001ea7dfa6c -[UIWindow _sendTouchesForEvent:] + 2472 (UIWindow.m:2204)
13 UIKitCore 0x00000001ea7e0cd0 -[UIWindow sendEvent:] + 3156 (UIWindow.m:2453)
14 UIKitCore 0x00000001ea7bffcc -[UIApplication sendEvent:] + 340 (UIApplication.m:10819)
15 UIKitCore 0x00000001ea88ee38 __dispatchPreprocessedEventFromEventQueue + 1620 (UIEventDispatcher.m:1678)
16 UIKitCore 0x00000001ea891830 __handleEventQueueInternal + 4740 (UIEventDispatcher.m:1937)
17 UIKitCore 0x00000001ea88a320 __handleHIDEventFetcherDrain + 152 (UIEventDispatcher.m:1905)
18 CoreFoundation 0x00000001bd44a0e0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24 (CFRunLoop.c:1980)
19 CoreFoundation 0x00000001bd44a060 __CFRunLoopDoSource0 + 88 (CFRunLoop.c:2015)
20 CoreFoundation 0x00000001bd449944 __CFRunLoopDoSources0 + 176 (CFRunLoop.c:2051)
21 CoreFoundation 0x00000001bd444810 __CFRunLoopRun + 1040 (CFRunLoop.c:2922)
22 CoreFoundation 0x00000001bd4440e0 CFRunLoopRunSpecific + 436 (CFRunLoop.c:3247)
23 GraphicsServices 0x00000001bf6bd584 GSEventRunModal + 100 (GSEvent.c:2245)
24 UIKitCore 0x00000001ea7a4c00 UIApplicationMain + 212 (UIApplication.m:4347)
25 AppName 0x0000000102c7d0f0 main + 60 (SMS.swift:12)
26 libdyld.dylib 0x00000001bcf02bb4 start + 4
Any idea on how I can determine the line that is causing the crash?
EDIT: I was able to get the user to send me a crash report stored on their device as suggested by #Václav, but it doesn't seem to contain much helpful information either:
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libswiftCore.dylib 0x0000000104e774ec 0x104c8c000 + 2012396
1 libswiftCore.dylib 0x0000000104e774ec 0x104c8c000 + 2012396
2 libswiftCore.dylib 0x0000000104e828cc 0x104c8c000 + 2058444
3 libswiftCore.dylib 0x0000000104e28fd4 0x104c8c000 + 1691604
4 libswiftCore.dylib 0x0000000104e830cc 0x104c8c000 + 2060492
5 libswiftCore.dylib 0x0000000104dd142c 0x104c8c000 + 1332268
6 AppName 0x00000001047fa948 0x1047e0000 + 108872
7 AppName 0x00000001047f4784 0x1047e0000 + 83844
8 UIKitCore 0x00000001e6fe6314 0x1e66fc000 + 9347860
9 UIKitCore 0x00000001e6a73d54 0x1e66fc000 + 3636564
10 UIKitCore 0x00000001e6a74074 0x1e66fc000 + 3637364
11 UIKitCore 0x00000001e6a73074 0x1e66fc000 + 3633268
12 UIKitCore 0x00000001e6bfaaf0 0x1e66fc000 + 5237488
13 UIKitCore 0x00000001e6bf57ec 0x1e66fc000 + 5216236
14 UIKitCore 0x00000001e6bf52cc 0x1e66fc000 + 5214924
15 UIKitCore 0x00000001e6bf509c 0x1e66fc000 + 5214364
16 UIKitCore 0x00000001e7020cb4 0x1e66fc000 + 9587892
17 UIKitCore 0x00000001e6ffffcc 0x1e66fc000 + 9453516
18 UIKitCore 0x00000001e70cee38 0x1e66fc000 + 10300984
19 UIKitCore 0x00000001e70d1830 0x1e66fc000 + 10311728
20 UIKitCore 0x00000001e70ca320 0x1e66fc000 + 10281760
21 CoreFoundation 0x00000001b9c8a0e0 0x1b9bdd000 + 708832
22 CoreFoundation 0x00000001b9c8a060 0x1b9bdd000 + 708704
23 CoreFoundation 0x00000001b9c89944 0x1b9bdd000 + 706884
24 CoreFoundation 0x00000001b9c84810 0x1b9bdd000 + 686096
25 CoreFoundation 0x00000001b9c840e0 0x1b9bdd000 + 684256
26 GraphicsServices 0x00000001bbefd584 0x1bbef2000 + 46468
27 UIKitCore 0x00000001e6fe4c00 0x1e66fc000 + 9341952
28 AppName 0x00000001047e5860 0x1047e0000 + 22624
29 libdyld.dylib 0x00000001b9742bb4 0x1b9742000 + 2996
There are a few different elements to this question, so let me try to break it down.
Why do I see line 0?
The Swift compiler does a fair amount of code generation before actually producing a final compiled binary. In this situation, line 0 is the compiler's way of telling you that it generated code while compiling TableViewController.swift, but that code doesn't correspond to a specific line in the original source.
Because you've got a specialized function here, I'm much more inclined to believe this is compiler-generated code. This usually means the compiler is working with generic types.
I'm disappointed that Apple communicates this event in this way, but there's not much we can do. My understanding is that DWARF can describe this kind of thing. But, either Apple doesn't use this facility, it isn't written to crash reports, or most likely both.
You can verify this behavior by using atos or dwarfdump to symbolication the address 0x0000000102c92748. My bet is it will output exactly the same thing - line 0. In the past I've used dwarfdump to poke around here to see if there was more info encoded in the dSYM, but I didn't find anything. It was a few years ago though, so things might have changed.
Might a 3rd party crash reporter help?
They all use the dSYM to symbolicate, so they cannot have more information than is contained in that file. It could be worth a shot, regardless, but I doubt you'll get anywhere on the line 0 thing.
However, they probably will be able to symbolicate the frames from libswiftCore.dylib, which could be very helpful.
Why did this crash happen?
This is the million dollar question.
I'd like to see the actual crash details. My guess is it is an illegal instruction, because you've crashed inside a swift runtime library. What's likely happening is the runtime has tripped on some kind of illegal state. Unwrapping a nil Optional could definitely be it. Could also be an out of bounds Range operation. I think that out-of-bounds array indexes might also fail in this way, but off the top of my head, I'm not sure.
What I would do is just take a close look at what's going on in TableViewController.sendSmsMessage(sender:). Pay close attention to the things listed above, particularly if it is interacting with any generic standard library functions.
I would also make an attempt to symbolicate those libswiftCore.dylib frames. Again, you can use atos for this, just by pointing it at the library itself and using the load address. I'm unsure where Xcode keeps the Swift libraries internally, so you might just use the copy of the lib that was bundled with your app.
Good luck!

App crash on Apple review - I can't reproduce it

I tested app on 10 different iOS devices, with and without Internet connection, with direct build and with Testflight build - app works. I tried different language settings, different regional settings - it works.
When I submit it for review it gets rejected for reason "Performance - 2.1" - app crash for them on first view.
Here is crash log Apple review team sent:
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x00000001000a5d6c
Triggered by Thread: 0
Filtered syslog:
None found
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 App name 0x00000001000a5d6c 0x100050000 + 351596
1 App name 0x00000001000a2dac 0x100050000 + 339372
2 UIKit 0x00000001882f0be8 -[UIApplication sendAction:to:from:forEvent:] + 100
3 UIKit 0x00000001882f0b64 -[UIControl sendAction:to:forEvent:] + 80
4 UIKit 0x00000001882d8870 -[UIControl _sendActionsForEvents:withEvent:] + 436
5 UIKit 0x00000001882f0454 -[UIControl touchesEnded:withEvent:] + 572
6 UIKit 0x00000001882f0084 -[UIWindow _sendTouchesForEvent:] + 804
7 UIKit 0x00000001882e8c20 -[UIWindow sendEvent:] + 784
8 UIKit 0x00000001882b904c -[UIApplication sendEvent:] + 248
9 UIKit 0x00000001882b7628 _UIApplicationHandleEventQueue + 6568
10 CoreFoundation 0x000000018311909c __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24
11 CoreFoundation 0x0000000183118b30 __CFRunLoopDoSources0 + 540
12 CoreFoundation 0x0000000183116830 __CFRunLoopRun + 724
13 CoreFoundation 0x0000000183040c50 CFRunLoopRunSpecific + 384
14 GraphicsServices 0x0000000184928088 GSEventRunModal + 180
15 UIKit 0x0000000188322088 UIApplicationMain + 204
16 App name 0x0000000100086d1c 0x100050000 + 224540
17 libdyld.dylib 0x0000000182bde8b8 start + 4
Whatever I try (as described at top of question) I can't make app crash. I really can't figure out what is different in settings that they use on their test devices and in settings on devices I use for test (please note again: I'm not testing on one or two - I tested on 10 devices). I also tried on several last versions of iOS and (of course) on version 9.3.3 they use for test - it works.
I would really appreciate some advice regarding crash log here or how to make some configuration to make this app crash (so I can debug it).

How to find, where is the crash happen - ios

I'm running my ios app in ipad 1, the following crash happen sometime while app is running, i don't know where the crash happen. This mostly happen in ios 5.1.1 . Here the crash log,
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0xf0000008
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libobjc.A.dylib 0x3387ef78 objc_msgSend + 16
1 UIKit 0x333ffa3a -[UIViewController unloadViewForced:] + 254
2 UIKit 0x335473a6 -[UIViewController purgeMemoryForReason:] + 58
3 Foundation 0x3507a4f8 __57-[NSNotificationCenter addObserver:selector:name:object:]_block_invoke_0 + 12
4 CoreFoundation 0x35c2c540 ___CFXNotificationPost_block_invoke_0 + 64
5 CoreFoundation 0x35bb8090 _CFXNotificationPost + 1400
6 Foundation 0x34fee3e4 -[NSNotificationCenter postNotificationName:object:userInfo:] + 60
7 Foundation 0x34fefc14 -[NSNotificationCenter postNotificationName:object:] + 24
8 UIKit 0x335120e6 -[UIApplication _performMemoryWarning] + 74
9 UIKit 0x335121e0 -[UIApplication _receivedMemoryNotification] + 168
10 libdispatch.dylib 0x33ffb252 _dispatch_source_invoke + 510
11 libdispatch.dylib 0x33ff8b1e _dispatch_queue_invoke$VARIANT$up + 42
12 libdispatch.dylib 0x33ff8e64 _dispatch_main_queue_callback_4CF$VARIANT$up + 152
13 CoreFoundation 0x35c332a6 __CFRunLoopRun + 1262
14 CoreFoundation 0x35bb649e CFRunLoopRunSpecific + 294
15 CoreFoundation 0x35bb6366 CFRunLoopRunInMode + 98
16 GraphicsServices 0x33951432 GSEventRunModal + 130
17 UIKit 0x3338ecce UIApplicationMain + 1074
18 MY Game 0x00079a90 0x75000 + 19088
19 MY Game 0x00079a50 0x75000 + 19024
As i understand from crash log, crash not happen due to my code. It's due low memory. Is that correct? How to find where the crash happen? Any suggestions.
As i understand from crash log, crash not happen due to my code. It's due low memory. Is that correct?
No, that's not correct.
Low memory is being reported, but your view controller is not responding properly. The most common cause of this is a retain cycle - see UIViewController purgeMemoryForReason: Crashing on iOS 5. In that answer, the retain cycle is in SVPullToRefresh , but yours could be elsewhere. The most common cause of retain cycles is not setting a delegate property to weak.
Once you figure out where the issue is, you can set breakpoints in viewDidUnload and ``didReceiveMemoryWarning`, simulate a memory warning, and step through your code to find the error.
Symbolication
Additionally, this crash report isn't symbolicated. Typically you'll want to symbolicate your crash report first. For example, see these lines:
18 MY Game 0x00079a90 0x75000 + 19088
19 MY Game 0x00079a50 0x75000 + 19024
In this case, as pointed out by Kerni, those two will just show start and main, so they won't help you in this instance. But generally, you should symbolicate your crash reports. (Search for "Xccode symbolicate crash logs" if you don't know how to do this.)

IOS app crashing only if installed from app store

I'm having a problem where if I run my app from installing it from the app store it's crashing (On multiple devices). But when I run the exact same code on the device from xCode it works fine.
I've been researching and the only suggestions I can find are to run in Release mode and change Optimization Level to fastest,smallest. Which I tried but it still doesn't crash. Heres the crash log I got:
Incident Identifier: 56DF41AE-4A6A-4328-A50E-03B2ECC245F5
CrashReporter Key: fabdf09dfea5dfb3a78e5ce49b1fda0291703647
Hardware Model: iPod4,1
Process: MobileScripts [356]
Path: /var/mobile/Applications/24524BCA-F897-45FE-87E5-3C807733C9C6/MobileScripts.app/MobileScripts
Identifier: MobileScripts
Version: ??? (???)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2013-12-12 13:28:29.474 -0600
OS Version: iOS 6.1.5 (10B400)
Report Version: 104
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread: 0
Last Exception Backtrace:
0 CoreFoundation 0x3195d29e __exceptionPreprocess + 158
1 libobjc.A.dylib 0x395dd97a objc_exception_throw + 26
2 CoreData 0x316fe0d6 -[NSPersistentStoreCoordinator executeRequest:withContext:error:] + 294
3 CoreData 0x317566de -[NSManagedObjectContext save:] + 726
4 MobileScripts 0x0002ce0a -[XML parser:didEndElement:namespaceURI:qualifiedName:] (XML.m:105)
5 Foundation 0x3227b28a _endElementNs + 298
6 libxml2.2.dylib 0x398f3e58 xmlParseEndTag2 + 612
7 libxml2.2.dylib 0x398f5546 xmlParseTryOrFinish + 1658
8 libxml2.2.dylib 0x398f4ce8 xmlParseChunk + 208
9 Foundation 0x32279d66 -[NSXMLParser parse] + 482
10 MobileScripts 0x0002c664 -[XML parseXml:] (XML.m:32)
11 MobileScripts 0x00034686 -[WebService parse] (WebService.m:114)
12 Foundation 0x322986f8 __65-[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:]_block_invoke_0 + 12
13 Foundation 0x321d81f4 -[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:] + 196
14 Foundation 0x321d8110 -[NSURLConnectionInternal _withActiveConnectionAndDelegate:] + 56
15 CFNetwork 0x3163a45a ___delegate_didFinishLoading_block_invoke_0 + 22
16 CFNetwork 0x31639b3e ___withDelegateAsync_block_invoke_0 + 50
17 CFNetwork 0x31661fc6 ___performAsync_block_invoke_068 + 14
18 CoreFoundation 0x318a3748 CFArrayApplyFunction + 172
19 CFNetwork 0x31662426 RunloopBlockContext::perform() + 70
20 CFNetwork 0x315c6038 MultiplexerSource::perform() + 184
21 CoreFoundation 0x3193267e __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 10
22 CoreFoundation 0x31931ee4 __CFRunLoopDoSources0 + 208
23 CoreFoundation 0x31930cb2 __CFRunLoopRun + 642
24 CoreFoundation 0x318a3eb8 CFRunLoopRunSpecific + 352
25 CoreFoundation 0x318a3d44 CFRunLoopRunInMode + 100
26 GraphicsServices 0x354562e6 GSEventRunModal + 70
27 UIKit 0x337b92fc UIApplicationMain + 1116
28 MobileScripts 0x0002c58e main (main.m:16)
29 libdyld.dylib 0x39a14b1c tlv_initializer + 4
I see that it doesn't like what I have on line 105 in XML.m, which is just a context save:
[context save:&saveError];
And like I said this line works just fine when I run it from xcode. Does anyone have any suggestions on how I can get more information on the exception or make this issue occur while debugging?
Thanks for any help.
EDIT:
I watched the device log during the crash and found out the exception is "'NSInternalInconsistencyException', reason: 'This NSPersistentStoreCoordinator has no persistent stores. It cannot perform a save operation.'". Any idea as to why this is only happening from the app store?
Connect the device to Xcode or the iPhone configurations program and watch the log.
Also how looks the scope of the save statement. Is there a try catch around it? You have a NSError object that should have the info. Usualy it get logged using NSLog.
Edit:
Where get the store created path wise and has the device enough room to create the store?
I am taking a guess. Are you delivering the persistence store with your app? Lets say a sqllight database that is part of the app? You may read files from your app but never write to. You need to move the pre made persistence store to one of the directories you have write access.

iOS: Crashlytics Crash Reports and Free RAM

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.

Resources