I'm having some weird issues with our app, it crashes when using some UIImage.
I get the image with [UIImage imageNamed:#"imageName"] from the image asset.
But on some device it returns nil which crash my app, but It should not be nil.
I've already checked and its running on the main thread, there is enough memory left (although it was running low).
The image is PDF as single vector image in the image assets, this should create the correct sizes of the images.
Can any one give me any pointers on how to resolve this issue?
Thread : Crashed: com.apple.main-thread
0 CoreFoundation 0x1844d7108 CFDataGetBytePtr + 36
1 Foundation 0x18545a848 bytesInEncoding + 204
2 CoreFoundation 0x1844e88d4 -[__NSCFString UTF8String] + 80
3 CoreUI 0x18d6827c0 -[CUIStructuredThemeStore _canGetRenditionWithKey:isFPO:lookForSubstitutions:] + 780
4 CoreUI 0x18d6a5614 -[CUICatalog _resolvedRenditionKeyFromThemeRef:withBaseKey:scaleFactor:deviceIdiom:deviceSubtype:sizeClassHorizontal:sizeClassVertical:memoryClass:graphicsClass:graphicsFallBackOrder:] + 1484
5 CoreUI 0x18d6a4784 -[CUICatalog namedLookupWithName:scaleFactor:deviceIdiom:deviceSubtype:sizeClassHorizontal:sizeClassVertical:] + 148
6 UIKit 0x18a3df338 __98-[_UIAssetManager imageNamed:scale:idiom:subtype:cachingOptions:sizeClassPair:attachCatalogImage:]_block_invoke + 424
7 UIKit 0x18a3df0d8 -[_UIAssetManager imageNamed:scale:idiom:subtype:cachingOptions:sizeClassPair:attachCatalogImage:] + 212
8 UIKit 0x18a4f1698 -[UIImageAsset imageWithTraitCollection:] + 404
9 UIKit 0x18a3df7c0 -[_UIAssetManager imageNamed:withTrait:] + 276
10 UIKit 0x189e7277c +[UIImage imageNamed:inBundle:compatibleWithTraitCollection:] + 220
11 UIKit 0x189ccb47c +[UIImage imageNamed:] + 124
12 Speakap 0x1000bef50 -[LoadingView commonInit] (LoadingView.m:74)
13 Speakap 0x1000beabc -[LoadingView initWithFrame:] (LoadingView.m:28)
14 Speakap 0x1001348dc -[BaseTableViewController viewDidLoad] (BaseTableViewController.m:32)
15 Speakap 0x1001570d4 -[BaseMessageViewController viewDidLoad] (BaseMessageViewController.m:66)
16 Speakap 0x10014aa34 -[MessageViewController viewDidLoad] (MessageViewController.m:37)
17 UIKit 0x189b8c098 -[UIViewController loadViewIfRequired] + 996
18 UIKit 0x189ba4350 -[UIViewController __viewWillAppear:] + 132
19 UIKit 0x189d3dfb4 -[UINavigationController _startCustomTransition:] + 1052
20 UIKit 0x189c4a190 -[UINavigationController _startDeferredTransitionIfNeeded:] + 688
21 UIKit 0x189c49e6c -[UINavigationController __viewWillLayoutSubviews] + 60
22 UIKit 0x189c49dd4 -[UILayoutContainerView layoutSubviews] + 208
23 UIKit 0x189b877ac -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 644
24 QuartzCore 0x189386b58 -[CALayer layoutSublayers] + 148
25 QuartzCore 0x189381764 CA::Layer::layout_if_needed(CA::Transaction*) + 292
26 QuartzCore 0x189381624 CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 32
27 QuartzCore 0x189380cc0 CA::Context::commit_transaction(CA::Transaction*) + 252
28 QuartzCore 0x189380a08 CA::Transaction::commit() + 512
29 UIKit 0x189b7d9d8 _afterCACommitHandler + 180
30 CoreFoundation 0x1845afbd0 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 32
31 CoreFoundation 0x1845ad974 __CFRunLoopDoObservers + 372
32 CoreFoundation 0x1845adda4 __CFRunLoopRun + 928
33 CoreFoundation 0x1844dcca0 CFRunLoopRunSpecific + 384
34 GraphicsServices 0x18f718088 GSEventRunModal + 180
35 UIKit 0x189bf4ffc UIApplicationMain + 204
36 Speakap 0x100162b24 main (main.m:14)
37 libdyld.dylib 0x19990a8b8 start + 4
I've experienced some "trouble" in memory management using [UIImage imageNamed:#""] within low memory context.
As the documentation says:
https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIImage_Class/index.html#//apple_ref/occ/clm/UIImage/imageNamed:
Discussion
This method looks in the system caches for an image object with the specified name and returns that object if it exists. If a matching image object is not already in the cache, this method locates and loads the image data from disk or asset catalog, and then returns the resulting object. In iOS 9 and later, this method is thread safe.
I don't know on which OS the crash happens, but it can be an idea.
Other point, does it still happens if your replace imageNamed: by imageWithContentOfFile: or initWithContentOfFile: ?
The memory management is different (no system cache):
https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIImage_Class/index.html#//apple_ref/occ/instm/UIImage/initWithContentsOfFile:
Discussion
This method loads the image data into memory and marks it as purgeable. If the data is purged and needs to be reloaded, the image object loads that data again from the specified path.
https://github.com/rickytan/RTImageAssets
install above plugin to xcode and go to file -> imageAssets ->Generate Missing assets.i will generate all missing images.
The only possibility I can see here, is that a specific device might not have the proper file. For example, if the device has Retina display and there is no #2x image in the image asset then it will be returned as nil etc.
My suggestion is to make sure all required sizes are actually exist inside the image asset + make sure to use asset group name for the imageNamed: parameter.
Also, are you testing it over various simulators or real devices?
It may possible that you are using hight resolution image & check on iPhone 4/4s or vise-a-versa.
Add all the sizes of images in image assets & then check for the image, whether it returns nil or not.
No need to mention #2x,#3x if we are using image assets,it will automatically take appropriate size from image assets.
Related
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).
Goal:
I want to symbolicate the "output" of [NSThread callStackSymbols].
Side Notes:
I know how to do that with crash logs. However, I need to investigate some problems where I would like to look at the call stack. Unfortunately these days the framework's addresses are all <redacted>. Causing a crash at the right points (or at the end - see end of my question) is not really acceptable, but if I cannot find another solution, it will be the way to go.
I have to run my tests on a device, so I cannot use the Simulator.
Current approach:
When I call this:
NSLog(#"call stack:\n%#", [NSThread callStackSymbols]);
I get this output:
2015-12-08 15:04:03.888 Conversion[76776:4410388] call stack:
(
0 Conversion 0x000694b5 -[ViewController viewDidLoad] + 128
1 UIKit 0x27259f55 <redacted> + 1028
...
9 UIKit 0x274f67a7 <redacted> + 134
10 FrontBoardServices 0x2b358ca5 <redacted> + 232
11 FrontBoardServices 0x2b358f91 <redacted> + 44
12 CoreFoundation 0x230e87c7 <redacted> + 14
...
16 CoreFoundation 0x23038ecd CFRunLoopRunInMode + 108
17 UIKit 0x272c7607 <redacted> + 526
18 UIKit 0x272c22dd UIApplicationMain + 144
19 Conversion 0x000767b5 main + 108
20 libdyld.dylib 0x34f34873 <redacted> + 2
)
("Conversion" in this output is the app.)
Now I can use this command to "symbolicate" addresses:
xcrun atos -o /path/to/Conversion.app -arch arm64 -l 0x0???
Run like that (of course with a proper value for -l), I can enter addresses like 0x000694b5 and it will spit out something like -[ViewController viewDidLoad] + 128. Of course the problem is the start address (the -l option's value).
When I have a crash log, I can get those. However, I would like to get away without a crash.
Questions:
Q1: Can I determine the start address at runtime and maybe include it in the log output so I can feed it to the atos -l option?
EDIT: It looks like this is possible like this: (thanks to NSProgrammer for answer https://stackoverflow.com/a/12464678/1396265)
#import <mach-o/dyld.h>
...
intptr_t slide = _dyld_get_image_vmaddr_slide(0);
const struct mach_header * load_addr = _dyld_get_image_header(0);
NSLog(#"slide %lx load addr %lx", (long)slide, (long)load_addr);
/EDIT
(As I am interested in the framework's method calls, I certainly need the start addresses of the frameworks. The app's start address changes frequently (randomization), I do not yet know, whether or not the framework's start addresses are randomized.)
Q2: Are there other approaches to investigating the methods in the call stack? (breakpoints are also rather clumsy in my scenario.)
EDIT:
Q3: How can I symbolicate the addresses of the frameworks? For instance where can I find the dSYM (or whatever it takes) for UIKit?
(For instance I have something at: ~/Library/Developer/Xcode/iOS\ DeviceSupport/9.1\ \(13B143\)/Symbols/System/Library/Frameworks/UIKit.framework/. I'll look into more details here.)
/EDIT
Maybe a solution:
One way might be, to save the log output to a file, and at the end of the tests cause a crash in the app. That way the crash log would reveal the start addresses and with the call stack information from the logs I should be able to symbolicate the callStackSymbols output. I will try that next.
Adding log snippets to the crash log worked well so far, so I'll add this as an answer for now. (Better answers are definitely welcome :-) )
Preparations:
Add callStackSymbols logging at the relevant places in the source code:
NSLog(#"call stack:\n%#", [NSThread callStackSymbols]);
Make the app crash (for instance when a certain screen is opened):
strcpy(0, "000");
Redirect logging output to a file:
FILE *logfile = freopen([pathForLog cStringUsingEncoding:NSASCIIStringEncoding], "a+", stderr);
Execution:
In Xcode run the app once, so it gets installed on the device, and then stop it.
Then start the app directly on the device, so Xcode won't catch the crash.
Use the app so that the call stack is logged (can be many times).
Eventually make the app crash (in my case, open a certain screen which calls the bad strcpy).
Getting the files:
In Xcode open "Window -> Devices", select the device, select the app and download the app container, so the log file can be extracted.
In the same screen open the device logs and export the crash log.
In Xcode open "Window -> Projects", select the project and make it show the derived data folder in the Finder (little arrow button to the right of the derived data path). In the derived data folder navigate to "Build/Products/Debug-iphoneos/" and copy MyApp.app and MyApp.app.dSYM.
Adjust the crash log:
For me it worked to add extra thread sections right before "Binary Images:". So find the location of "Binary Images:". Insert a line "Thread 9999:". Copy&paste the call stack dumps and remove the leading whitespace columns so that it looks like this:
2015-12-09 15:28:58.971 MyApp[21376:3050653] call tree (
Thread 9999:
0 MyApp 0x00000001001d95f8 -[MyClass myMethod:] + 100
1 UIKit 0x000000018a5fc2ac <redacted> + 172
2 UIKit 0x000000018a5d5ca4 <redacted> + 88
3 UIKit 0x000000018a5d5b8c <redacted> + 460
4 UIKit 0x000000018a5d5cc0 <redacted> + 116
5 UIKit 0x000000018a5d5b8c <redacted> + 460
6 UIKit 0x000000018a5d5cc0 <redacted> + 116
7 UIKit 0x000000018a5d5b8c <redacted> + 460
8 UIKit 0x000000018a8e85ac <redacted> + 460
9 UIKit 0x000000018a5d4abc <redacted> + 96
10 UIKit 0x000000018a935b7c <redacted> + 344
11 UIKit 0x000000018a9306f8 <redacted> + 124
12 UIKit 0x000000018aa584d8 <redacted> + 44
13 UIKit 0x000000018a933d9c <redacted> + 188
14 UIKit 0x000000018a70b668 <redacted> + 116
15 UIKit 0x000000018a70b454 <redacted> + 252
16 UIKit 0x000000018a70af38 <redacted> + 1404
17 UIKit 0x000000018a70a9a8 <redacted> + 124
18 UIKit 0x000000018a616d3c <redacted> + 312
19 UIKit 0x000000018a616bc4 <redacted> + 108
20 QuartzCore 0x0000000189dddc2c <redacted> + 284
21 libdispatch.dylib 0x000000019a3a96a8 <redacted> + 16
22 libdispatch.dylib 0x000000019a3aedb0 _dispatch_main_queue_callback_4CF + 1844
23 CoreFoundation 0x00000001850001f8 <redacted> + 12
24 CoreFoundation 0x0000000184ffe060 <redacted> + 1628
25 CoreFoundation 0x0000000184f2cca0 CFRunLoopRunSpecific + 384
26 GraphicsServices 0x000000018ff94088 GSEventRunModal + 180
27 UIKit 0x000000018a644ffc UIApplicationMain + 204
28 MyApp 0x0000000100093918 main + 124
29 libdyld.dylib 0x000000019a3da8b8 <redacted> + 4
Binary Images:
...
The "Thread 9999:" line makes the symbolicatecrash script want to symbolicate the next lines. I chose 9999 so I know, that these were my added sections.
Run symbolication:
Find the symbolicatecrash script:
$ find /Applications/Xcode.app -name symbolicatecrash -type f
/Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash
$
The symbolication command goes almost like this:
$ symbolicatecrash myapp.crash MyApp.app.dSYM > myapp-sym.crash
You need to set DEVELOPER_DIR and prepend the path to the script, so eventually it looks like this:
$ DEVELOPER_DIR='/Applications/Xcode.app/Contents/Developer' /Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash myapp.crash MyApp.app.dSYM > myapp-sym.crash
Or wrapped for better viewing pleasure:
$ DEVELOPER_DIR='/Applications/Xcode.app/Contents/Developer' ...
/Applications/Xcode.app/Contents/SharedFrameworks/ ...
DTDeviceKitBase.framework/Versions/A/Resources/ ...
symbolicatecrash myapp.crash MyApp.app.dSYM > myapp-sym.crash
The result:
The symbolicated snippets now look like this:
2015-12-09 15:28:58.971 MyApp[21376:3050653] call tree (
Thread 9999:
0 MyApp 0x00000001001d95f8 -[MyClass myMethod:] (MyFile.m:15)
1 UIKit 0x000000018a5fc2ac -[UIScrollView _willMoveToWindow:] + 172
2 UIKit 0x000000018a5d5ca4 __85-[UIView(Hierarchy) _makeSubtreePerformSelector:withObject:withObject:copySublayers:]_block_invoke + 88
3 UIKit 0x000000018a5d5b8c -[UIView(Hierarchy) _makeSubtreePerformSelector:withObject:withObject:copySublayers:] + 460
4 UIKit 0x000000018a5d5cc0 __85-[UIView(Hierarchy) _makeSubtreePerformSelector:withObject:withObject:copySublayers:]_block_invoke + 116
5 UIKit 0x000000018a5d5b8c -[UIView(Hierarchy) _makeSubtreePerformSelector:withObject:withObject:copySublayers:] + 460
6 UIKit 0x000000018a5d5cc0 __85-[UIView(Hierarchy) _makeSubtreePerformSelector:withObject:withObject:copySublayers:]_block_invoke + 116
7 UIKit 0x000000018a5d5b8c -[UIView(Hierarchy) _makeSubtreePerformSelector:withObject:withObject:copySublayers:] + 460
8 UIKit 0x000000018a8e85ac __UIViewWillBeRemovedFromSuperview + 460
9 UIKit 0x000000018a5d4abc -[UIView(Hierarchy) removeFromSuperview] + 96
10 UIKit 0x000000018a935b7c __71-[UIPresentationController _initViewHierarchyForPresentationSuperview:]_block_invoke596 + 344
11 UIKit 0x000000018a9306f8 -[UIPresentationController transitionDidFinish:] + 124
12 UIKit 0x000000018aa584d8 -[_UICurrentContextPresentationController transitionDidFinish:] + 44
13 UIKit 0x000000018a933d9c __56-[UIPresentationController runTransitionForCurrentState]_block_invoke_2 + 188
14 UIKit 0x000000018a70b668 -[_UIViewControllerTransitionContext completeTransition:] + 116
15 UIKit 0x000000018a70b454 -[UITransitionView notifyDidCompleteTransition:] + 252
16 UIKit 0x000000018a70af38 -[UITransitionView _didCompleteTransition:] + 1404
17 UIKit 0x000000018a70a9a8 -[UITransitionView _transitionDidStop:finished:] + 124
18 UIKit 0x000000018a616d3c -[UIViewAnimationState sendDelegateAnimationDidStop:finished:] + 312
19 UIKit 0x000000018a616bc4 -[UIViewAnimationState animationDidStop:finished:] + 108
20 QuartzCore 0x0000000189dddc2c CA::Layer::run_animation_callbacks(void*) + 284
21 libdispatch.dylib 0x000000019a3a96a8 _dispatch_client_callout + 16
22 libdispatch.dylib 0x000000019a3aedb0 _dispatch_main_queue_callback_4CF + 1844
23 CoreFoundation 0x00000001850001f8 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
24 CoreFoundation 0x0000000184ffe060 __CFRunLoopRun + 1628
25 CoreFoundation 0x0000000184f2cca0 CFRunLoopRunSpecific + 384
26 GraphicsServices 0x000000018ff94088 GSEventRunModal + 180
27 UIKit 0x000000018a644ffc UIApplicationMain + 204
28 MyApp 0x0000000100093918 main (main.m:16)
29 libdyld.dylib 0x000000019a3da8b8 <redacted> + 4
Binary Images:
...
Unless I find an easier approach, this will be the way to go for now for me. It may be useful to create a script which pulls the call stacks from the log file, removes the leading whitespace and inserts those into the crash log.
SYMBOLICATECRASH
Apple ships a script with XCode that expedites the symbolication process of a crash report in its entirety. If you have a dSYM, your app binary and a crash report, this is probably the easiest method of symbolication. You don’t have to worry about any of the addresses – this script will parse the whole crash dump file and use ATOS to resolve all of the addresses into symbols for you.
Locate the “symbolicatecrash” on your system:
cd /Applications/Xcode.app
find . -name symbolicatecrash
Export the DEVELOPER_DIR environment variable, if it doesn’t exist
export DEVELOPER_DIR="/Applications/Xcode.app/Contents/Developer"
Copy your .app binary, the crash report, and the .dSYM file to a temporary folder (ex. ~/tmp).
Run the script like our example below:
/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash -v ApteligentExampleApp.crash ApteligentExampleApp.app.dSYM/
If all goes well, the script should symbolicate your entire crash file and output the result to your terminal window. This script doesn’t do anything you couldn’t do manually with ATOS or another tool, but it will get you what you need much quicker.
Source
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.
my app crash in [UIView(CALayer Delegate) drawLayer:inContext: ,the most difficult is there are not any code of my app in the crash log and i cannot reproduce it .This issue cost me several days and I still have no idea. Any ideas you guys provide, I will try. Thank you for your help.
crash log:
0 libobjc.A.dylib objc_msgSend_stret (in libobjc.A.dylib) + 18
1 UIKit -[UIView(CALayerDelegate) drawLayer:inContext:]
2 QuartzCore -[CALayer drawInContext:] (in QuartzCore) + 116
3 QuartzCore CABackingStoreUpdate_ (in QuartzCore) + 1782
4 QuartzCore CA::Layer::display_() (in QuartzCore) + 972
5 QuartzCore CA::Layer::display() (in QuartzCore) + 128
6 QuartzCore CA::Layer::display_if_needed(CA::Transaction*) (in QuartzCore)
7 QuartzCore CA::Context::commit_transaction(CA::Transaction*)
8 QuartzCore CA::Transaction::commit() (in QuartzCore) + 314
9 QuartzCore CA::Transaction::pop() (in QuartzCore) + 126
10 QuartzCore +[CATransaction commit] (in QuartzCore) + 34
11 UIKit _UIWindowUpdateVisibleContextOrder (in UIKit) + 188
12 UIKit +[UIWindow _prepareWindowsForAppResume] (in UIKit) + 10
13 UIKit -[UIApplication _handleApplicationResumeEvent:] (in UIKit) + 74
14 UIKit -[UIApplication handleEvent:withNewEvent:] (in UIKit) + 1080
15 UIKit -[UIApplication sendEvent:] (in UIKit) + 54
16 UIKit _UIApplicationHandleEvent (in UIKit) + 5808
The solution is the try and sectionalize the problem. Assuming you have one view that is causing this, then the most likely explanation is that something in the view is corrupt or has been released.
1) Did you try turning on Zombies, to see if some dealloc'd item is getting messaged?
2) In the view that is showing (or about to show) when the crash starts, either remove items one at a time, or remove them all from the view, and start adding them one by one. A good way to do this type of messy works is just copy your project folder, save the old one, and go cut chunks of code out so you can get to a working point.
My guess is that something is getting released before it should.