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!
Related
I use Fabric to log crash on my iOS App.
Today, I came across some crash related to DiskCookies. I really don't know what it means.
Crashed: diskcookies
0 CoreFoundation 0x1bd00136 CFNotificationCenterPostNotification + 53
1 libsystem_malloc.dylib 0x1b5d9cf3 szone_malloc_should_clear + 3240
2 CFNetwork 0x1c44a359 DiskCookieStorage::writeFileCompletely0(DiskCookieStorage*, FilePathStat*, MemoryCookies const*, __CFData const*, TracerData*, int) + 634
3 CFNetwork 0x1c44a49d DiskCookieStorage::_asyncWriteFileCompletely(void*) + 174
4 libdispatch.dylib 0x1b4a1783 _dispatch_client_callout + 22
5 libdispatch.dylib 0x1b4ada35 _dispatch_barrier_sync_f_invoke + 50
6 CFNetwork 0x1c44b09d DiskCookieStorage::syncStorageWithCompletionLocked(unsigned char, void () block_pointer) + 2220
7 CFNetwork 0x1c44277b ___CFHTTPCookieStorageFlushCookieStores_block_invoke + 86
8 CoreFoundation 0x1bcf5447 __CFDictionaryApplyFunction_block_invoke + 20
9 CoreFoundation 0x1bce0634 CFBasicHashApply + 120
10 CoreFoundation 0x1bce94c1 CFDictionaryApplyFunction + 152
11 CFNetwork 0x1c44270f _CFHTTPCookieStorageFlushCookieStores + 140
12 libsystem_c.dylib 0x1b53720d __cxa_finalize_ranges + 290
13 libsystem_c.dylib 0x1b4f61b3 exit + 12
14 Comico 0x97a74f UnityGetGLViewController + 4756906
15 Comico 0x97a265 UnityGetGLViewController + 4755648
16 Comico 0x980a6b UnityGetGLViewController + 4782278
17 Comico 0x96dfb5 UnityGetGLViewController + 4705808
18 Comico 0x96da59 UnityGetGLViewController + 4704436
19 Comico 0x200fe3 -[AppDelegate setUpAppGuardWithUserID:] (AppDelegate.m:1303)
20 Comico 0x1ff967 __36-[AppDelegate dologinInCallLoginAPI]_block_invoke (AppDelegate.m:1026)
21 Comico 0x13f69b __42-[NCLoginRAPIManager loginWithCompletion:]_block_invoke (NCLoginRAPIManager.m:97)
22 Comico 0xde19f -[NCRAPICompletion performBlockWithOperation:] (NCRAPICompletion.m:94)
23 CoreFoundation 0x1bd06323 -[NSArray makeObjectsPerformSelector:withObject:] + 218
24 Comico 0x3adf0d -[NCRAPIOperationRegister performCompletionBlockOfOperation:] (NCRAPIOperationRegister.m:67)
25 Comico 0x251ce1 __51-[NCRAPIManager callRAPIWithAPIRequest:completion:]_block_invoke_2 (NCRAPIManager.m:65)
26 libdispatch.dylib 0x1b4a1797 _dispatch_call_block_and_release + 10
27 libdispatch.dylib 0x1b4a1783 _dispatch_client_callout + 22
28 libdispatch.dylib 0x1b4a5d05 _dispatch_main_queue_callback_4CF + 902
29 CoreFoundation 0x1bd8fd69 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 8
30 CoreFoundation 0x1bd8de19 __CFRunLoopRun + 848
31 CoreFoundation 0x1bce11af CFRunLoopRunSpecific + 470
32 CoreFoundation 0x1bce0fd1 CFRunLoopRunInMode + 104
33 GraphicsServices 0x1d48bb41 GSEventRunModal + 80
34 UIKit 0x21069a53 UIApplicationMain + 150
35 Comico 0x20dc39 main (main.m:19)
36 libdyld.dylib 0x1b4ce4eb start + 2
I believe someone is trying to modify the path where network library put data to. Does anyone have any other theory or have some experience on this crash?
From the stack trace you posted here is my theory.
Frame 14 indicates that you've got a Unity application, and it's doing its thing running OpenGL.
Frame 13 is really interesting. It seems like the Unity UnityGetGLViewController (which I assume is not written by you) has called exit. This is surprising behavior, but it gives lots of clues on the rest of the stack.
Frames 12-2 look like the network stack is just doing some work on application exit (triggered by UnityGetGLViewController). Seems like it is just writing some cookie-related stuff to disk. I wouldn't worry about this.
Frame 0 and 1 are really suspect. I have a very hard time believing that malloc calls into CoreFoundation. If I had to guess, I would say that frame 0 is correct, and frame 1 has been mis-symbolicated or incorrectly unwound.
It's very unusual to call exit in iOS applications. While it is technically API, I doubt it is heavily tested. My bet is that there are some dangling pointer and/or object lifecycle issues related to the use of exit and you are seeing it here.
What I would do is see if Unity has any documentation around UnityGetGLViewController calling exit. I'd also check in with the Fabric people about frames 1 and 0. I don't see how both could be correct. And, finally, I might consider opening a bug with Apple. However, Apple usually doesn't like looking at non-Apple crash reports. So, that last one is probably a long-shot.
In my app, I have used one textfield. When tap on textfield the device keyboard will appear and than I type some text in that textfield. On that time the app get crashed in iPad Pro 11.2.5 version. I don't know why the app getting crashed because the same code works perfect in iPad Pro 10.3 version. Please review the my crash analytics report below
Crashed: com.apple.main-thread
0 libobjc.A.dylib 0x184410430 objc_msgSend + 16
1 CoreFoundation 0x18514513c __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 20
2 CoreFoundation 0x1851446dc _CFXRegistrationPost + 420
3 CoreFoundation 0x185144440 ___CFXNotificationPost_block_invoke + 60
4 CoreFoundation 0x1851c1e24 -[_CFXNotificationRegistrar find:object:observer:enumerator:] + 1408
5 CoreFoundation 0x18507ad60 _CFXNotificationPost + 380
6 Foundation 0x185aa7348 -[NSNotificationCenter postNotificationName:object:userInfo:] + 68
7 UIFoundation 0x18f8c4570 -[NSTextStorage processEditing] + 240
8 UIFoundation 0x18f8c41d8 -[NSTextStorage endEditing] + 92
9 UIKit 0x18e914368 -[UITextInputController _insertText:fromKeyboard:] + 488
10 UIKit 0x18e9136d0 -[UITextInputController insertText:] + 400
11 UIKit 0x18ead3518 -[UIFieldEditor insertFilteredText:] + 968
12 UIKit 0x18f3eb3a0 -[UITextField insertFilteredText:] + 104
13 UIKit 0x18e91343c -[UIKeyboardImpl insertText:] + 136
14 UIKit 0x18ebd735c -[UIKeyboardImpl performKeyboardOutput:] + 756
15 UIKit 0x18ebd665c __55-[UIKeyboardImpl handleKeyboardInput:executionContext:]_block_invoke_2 + 256
16 UIKit 0x18f431fac -[UIKeyboardTaskEntry execute:] + 192
17 UIKit 0x18e7975f0 -[UIKeyboardTaskQueue continueExecutionOnMainThread] + 384
18 Foundation 0x185baf2e4 __NSThreadPerformPerform + 340
19 CoreFoundation 0x18515b77c __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24
20 CoreFoundation 0x18515b6fc __CFRunLoopDoSource0 + 88
21 CoreFoundation 0x18515af84 __CFRunLoopDoSources0 + 204
22 CoreFoundation 0x185158b5c __CFRunLoopRun + 1048
23 CoreFoundation 0x185078c58 CFRunLoopRunSpecific + 436
24 GraphicsServices 0x186f24f84 GSEventRunModal + 100
25 UIKit 0x18e7d15c4 UIApplicationMain + 236
26 Q App 0x1050b756c main (main.m:16)
27 libdyld.dylib 0x184b9856c start + 4
As my crash reports, I didn't use NotificationCenter/observer in that screen. But the crash reports are showing in the NotificationCenter. Please Any know the solution for this ?
Note: The following is without knowing all required details because you did not provide any source code on how you implemented the feature nor does the crash report shown here contain any information about the exception code/signal being thrown.
The top frame shows the method objc_msgSend being invoked. This method is always used when the runtime tries to send a message (method) to an object. And crashes in this method usually mean the object doesn't exist any longer which means it was deallocated but your code still holds a reference.
So this looks like a memory management issue in your code. Without your actual implementation it is impossible to provide any meaningful help.
The best way to debug this is to run the app in debug mode and the device attached to Xcode and get more details. The Instrument tools can also help finding out where the problem is.
React Native should automatically fallback to using the offline bundle, which it saves on the first run, if it cannot find a running packager. This is mentioned in Running react-native app on iOS device using offline bundle.
However, in my case, after disconnecting the phone from the WiFi and launching the app, it just hangs on a pre-cached page (or image of a page), and it's often the last loaded page (i.e. the last page that was loaded when the app was connected to the packager). This one is counter-intuitive because you'd think that after closing the app, it wouldn't persist any local state.
I'm not sure why this happens in my case. Here is the relevant log-trace from my device and it's crashing in isPackagerRunning which seems to be attempting to make some sort request to a URL. Should it even be attempting to do this? I can try logging the URL it's trying to connect to I suppose.
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x0000000186eaf260 semaphore_wait_trap + 8
1 libdispatch.dylib 0x0000000186d9d5e8 _os_semaphore_wait + 24
2 libdispatch.dylib 0x0000000186d9cca0 _dispatch_semaphore_wait_slow + 140
3 CFNetwork 0x000000018858eb9c CFURLConnectionSendSynchronousRequest + 284
4 CFNetwork 0x00000001885bb154 +[NSURLConnection sendSynchronousRequest:returningResponse:error:] + 120
5 resiShare 0x00000001003d4334 -[RCTBundleURLProvider isPackagerRunning:] (RCTBundleURLProvider.m:76)
6 resiShare 0x00000001003d45e4 -[RCTBundleURLProvider guessPackagerHost] (RCTBundleURLProvider.m:92)
7 resiShare 0x00000001003d47f4 -[RCTBundleURLProvider packagerServerHost] (RCTBundleURLProvider.m:106)
8 resiShare 0x00000001003d49b8 -[RCTBundleURLProvider jsBundleURLForBundleRoot:fallbackResource:] (RCTBundleURLProvider.m:123)
9 resiShare 0x00000001000cad6c -[AppDelegate application:didFinishLaunchingWithOptions:] (AppDelegate.m:23)
10 UIKit 0x000000018e0732dc -[UIApplication _handleDelegateCallbacksWithOptions:isSuspended:restoreState:] + 380
11 UIKit 0x000000018e27f800 -[UIApplication _callInitializationDelegatesForMainScene:transitionContext:] + 3452
12 UIKit 0x000000018e2852a8 -[UIApplication _runWithMainScene:transitionContext:completion:] + 1684
13 UIKit 0x000000018e299de0 __84-[UIApplication _handleApplicationActivationWithScene:transitionContext:completion:]_block_invoke.3151 + 48
14 UIKit 0x000000018e28253c -[UIApplication workspaceDidEndTransaction:] + 168
15 FrontBoardServices 0x0000000189a7b884 __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ + 36
16 FrontBoardServices 0x0000000189a7b6f0 -[FBSSerialQueue _performNext] + 176
17 FrontBoardServices 0x0000000189a7baa0 -[FBSSerialQueue _performNextFromRunLoopSource] + 56
18 CoreFoundation 0x0000000187e81424 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24
19 CoreFoundation 0x0000000187e80d94 __CFRunLoopDoSources0 + 540
20 CoreFoundation 0x0000000187e7e9a0 __CFRunLoopRun + 744
21 CoreFoundation 0x0000000187daed94 CFRunLoopRunSpecific + 424
22 UIKit 0x000000018e06c45c -[UIApplication _run] + 652
23 UIKit 0x000000018e067130 UIApplicationMain + 208
24 resiShare 0x00000001000cb1d0 main (main.m:16)
25 libdyld.dylib 0x0000000186dbd59c start + 4
I've posted a workaround here - https://github.com/facebook/react-native/issues/10187 in the hopes that someone better versed with objective-c and url loading will take a look and put in the proper fix. Hope this helps. Thanks.
The issue is that a synchronous request is made from the main thread at load time in order to figure out whether the react packager (remote server running on the same network) is accessible. This can take awhile for reasons beyond my knowledge (if someone can expound on this, I'd be grateful), but apple will crash the app if this takes longer than 19 seconds (approx).
We received the stack trace below from Flurry. It was captured from a user's device, and we have no way of tracing it. It doesn't list lines from our code base ... how can we troubleshoot the stack trace and isolate the problem?
Full Stack Trace:
0 libGPUSupportMercury.dylib 0x34d068f6 <redacted> + 9
1 IMGSGX535GLDriver 0x2f04050f <redacted> + 122
2 GLEngine 0x32515a01 <redacted> + 172
3 GLEngine 0x3251590f _gliPresentViewES + 134
4 OpenGLES 0x325200cd <redacted> + 64
5 SpriteKit 0x32990191 -[SKView _renderContent] + 1216
6 libdispatch.dylib 0x3af1381f <redacted> + 22
7 libdispatch.dylib 0x3af25dd7 <redacted> + 26
8 SpriteKit 0x3298fca3 -[SKView renderContent] + 82
9 SpriteKit 0x3298d633 <redacted> + 130
10 SpriteKit 0x329b00eb -[SKDisplayLink _callbackForNextFrame:] + 254
11 QuartzCore 0x32766df3 <redacted> + 98
12 QuartzCore 0x32766b9d <redacted> + 344
13 IOMobileFramebuffer 0x354df75d <redacted> + 104
14 IOKit 0x30f69451 _IODispatchCalloutFromCFMessage + 248
15 CoreFoundation 0x3023eef9 <redacted> + 136
16 CoreFoundation 0x30249ab7 <redacted> + 34
17 CoreFoundation 0x30249a53 <redacted> + 346
18 CoreFoundation 0x30248227 <redacted> + 1398
19 CoreFoundation 0x301b2f4f _CFRunLoopRunSpecific + 522
20 CoreFoundation 0x301b2d33 _CFRunLoopRunInMode + 106
21 GraphicsServices 0x350b7663 _GSEventRunModal + 138
22 UIKit 0x32afe16d _UIApplicationMain + 1136
23 <OurClassName> 0x000af494 __mh_execute_header + 345236
24 libdyld.dylib 0x3af38ab7 <redacted> + 2
First, you need to get the base address for each of the modules listed on the left side (your app, plus every system library), because of Address Space Layout Randomization (ASLR). Many in-app stack trace reporting tools like PLCrashReporter can store this information in their report.
Next, you need to get the debug symbols for each module. For your app, when you build, it should produce a .dSym file, which contains the information that allows you to get the method and line numbers from the address. You need to make sure to get the exact .dSym that corresponds to the build that produced the crash, because each build is different.
For system libraries, the debug symbols are downloaded by Xcode the first time you connect a device to Xcode using a particular build of the OS. They are stored in /Users/<yourusername>/Library/Developer/Xcode/iOS DeviceSupport/. Note that sometimes versions of the OS will have multiple builds (betas, or different build for different devices); you need to get the OS build that the crash happened on, which means your stack trace will also need to store that information. It also needs to be an OS build that your Xcode has seen or else it won't have downloaded the information. For system modules, you will only get the function name and not the line number (which wouldn't be useful anyway since they are not open source).
Then, you can use the tool atos, give it an address, a load address (the base address of the module at issue), the architecture (for an app that includes code for multiple architectures), and it will output the symbol information for that address.
I'm getting crash reports for my iOS app with the following or similar stack in the crashed thread:
0 TextInput 0x0003149a TIInputManager::apply_case_changes_to_result(std::vector >&, KB::Hashmap const&, std::vector > const&) const + 402
1 TextInput 0x00030bf3 TIInputManager::lookup() + 863
2 TextInput 0x000307ad TIInputManager::autocorrection() + 61
3 TextInput 0x00042d21 -[TIKeyboardInputManagerZephyr autocorrection] + 137
4 UIKit 0x0011a319 -[UIKeyboardImpl generateCandidatesWithOptions:] + 377
5 UIKit 0x00133071 -[UIKeyboardImpl addInputString:fromVariantKey:] + 2597
6 UIKit 0x00130f8d -[UIKeyboardImpl handleKeyEvent:] + 1453
7 UIKit 0x001308b7 -[UIKeyboardLayoutStar sendStringAction:forKey:isPopupVariant:] + 487
8 UIKit 0x0012f3ad -[UIKeyboardLayoutStar touchUp:] + 3101
9 UIKit 0x0012e737 -[UIKeyboardLayout touchesEnded:withEvent:] + 387
10 UIKit 0x000165f9 -[UIWindow _sendTouchesForEvent:] + 525
11 UIKit 0x00003809 -[UIApplication sendEvent:] + 381
12 UIKit 0x00003123 _UIApplicationHandleEvent + 6155
13 GraphicsServices 0x000065a3 _PurpleEventCallback + 591
14 GraphicsServices 0x000061d3 PurpleEventCallback + 35
15 CoreFoundation 0x00097173 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 35
16 CoreFoundation 0x00097117 __CFRunLoopDoSource1 + 139
17 CoreFoundation 0x00095f99 __CFRunLoopRun + 1385
18 CoreFoundation 0x00008ebd CFRunLoopRunSpecific + 357
19 CoreFoundation 0x00008d49 CFRunLoopRunInMode + 105
20 GraphicsServices 0x000052eb GSEventRunModal + 75
21 UIKit 0x00057301 UIApplicationMain + 1121
22 MyApp 0x0000294b main (main.mm:8)
Only the bottom-most line (main) is mine. It looks like the crash is somewhere in an touch up event handler within the text input framework, and it has to do with autocorrect.
Those crashes come with disheartening consistency - this looks like a subtle bug of mine, not that of iOS itself. The call stack is inconsistent - sometimes it ends in UIKit, sometimes in libobjc. The iOS version, however, seems to be consistently 6.x.
Any idea how to debug this, please?
EDIT: SIGSEGV/SEGV_ACCERR in thread 0. The error address varies - sometimes, it's zero, sometimes not.
This is actually an error with Apple. Go into your Settings on the simulator (the Settings app on the sim, that is) and turn off auto correction.
I've seen the same on iOS 6.1.3 (twice) and 6.1.4 (once), all in the field reported as crashlogs. All seem to be nil pointer dereferences deep within Apple's C++ code for . I don't think that there is anything that we can do beyond filing a bug report with Apple (I've raised one listed as: 15573020). Apple treat duplicate reports as an indicator of prioritisation of bugs so if you have suffered I suggest that you add a report at https://bugreport.apple.com and reference the report I have provided.