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.
Related
I am getting some auto layout assertions due to UI tasks getting called from background thread. To track this I added a symbolic breakpoint for
-[NSISEngine _optimizeWithoutRebuilding]
This breakpoint is getting called but I don't have the stack trace from my code. I checked all the threads when it hit this assertion and no useful information from where it was invoked in my code.
This application is modifying the autolayout engine from a background thread after the engine was accessed from the main thread. This can lead to engine corruption and weird crashes.
Stack:(
0 Foundation 0x000000010cd1752a _AssertAutolayoutOnAllowedThreadsOnly + 77
1 Foundation 0x000000010cd17251 -[NSISEngine _optimizeWithoutRebuilding] + 61
2 Foundation 0x000000010cd1717f -[NSISEngine optimize] + 108
3 Foundation 0x000000010cd123a5 -[NSISEngine performPendingChangeNotifications] + 84
4 UIKitCore 0x00000001187e7cc8 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 2192
5 QuartzCore 0x000000010da41eae -[CALayer layoutSublayers] + 173
6 QuartzCore 0x000000010da46b88 _ZN2CA5Layer16layout_if_neededEPNS_11TransactionE + 396
7 QuartzCore 0x000000010da52ee4 _ZN2CA5Layer28layout_and_display_if_neededEPNS_11TransactionE + 72
8 QuartzCore 0x000000010d9c23aa _ZN2CA7Context18commit_transactionEPNS_11TransactionE + 328
9 QuartzCore 0x000000010d9f9584 _ZN2CA11Transaction6commitEv + 608
10 QuartzCore 0x000000010d9fa435 _ZN2CA11Transaction14release_threadEPv + 201
11 libsystem_pthread.dylib 0x0000000115cd66ab _pthread_tsd_cleanup + 551
12 libsystem_pthread.dylib 0x0000000115cd9655 _pthread_exit + 70
13 libsystem_pthread.dylib 0x0000000115cd643a _pthread_wqthread_exit + 74
14 libsystem_pthread.dylib 0x0000000115cd5644 _pthread_wqthread + 472
15 libsystem_pthread.dylib 0x0000000115cd53fd start_wqthread + 13
Question : Is there some other method I should put a breakpoint in or any better way to track this ?
Update: I added the breakpoints as mentioned, it hit the breakpoint but the call stack doesn't show what caused the breakpoint. See screenshots.
I have a simple tableview on a screen, initially I don't get these assertions, just staying on that screen for a while triggers these assertions.
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.
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 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.
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.