I have a crashgroup that I don't understand and which I did not manage to reproduce yet. Does anyone have a clue what is going on here? To me it look like there is a view that is created, and maybe deallocated right away? In fact I also often see reference to the init method of some of my views just before this stacktrace, But the views are varying so it seemes that I have this problem in many places of my app. :-(
Application Specific Information:
objc_msgSend() selector name: retain
Thread 0 Crashed:
0 libobjc.A.dylib 0x0000000182b81bd0 objc_msgSend + 16
1 Foundation 0x0000000183dd68e4 -[NSObject(NSKeyValueObserverNotification) willChangeValueForKey:] + 320
2 QuartzCore 0x0000000185bf3374 CA::Layer::set_delegate(objc_object*) + 68
3 UIKit 0x00000001881f6538 -[UIView _createLayerWithFrame:] + 576
4 UIKit 0x00000001881f5ff8 UIViewCommonInitWithFrame + 684
5 UIKit 0x00000001881f5ce8 -[UIView initWithFrame:] + 136
Is that fact that is says: objc_msgSend() selector name: retain some kind of clue? To me it look like retain is being called, but why should it crash then?
This is a memory management issue. You will need to replicate the conditions of the crash with Zombies turned on. Some object has vanished out from under its pointer, and Zombies will tell you what object it is.
The detail article on this kind of crash:
http://www.sealiesoftware.com/blog/archive/2008/09/22/objc_explain_So_you_crashed_in_objc_msgSend.html
Related
We are seeing a strange crash in our map based iOS app that I cannot figure out. Basically as some point the following lines of code repeat over and over, more than 100 times in crash log:
6 VectorKit 0x000000019050c6f8 __86-[VKMapCameraController _animateToPosition:pitch:yaw:duration:timingCurve:completion:]_block_invoke347 + 40
7 VectorKit 0x0000000190485a30 -[VKAnimation _stopAnimation:] + 140
8 VectorKit 0x0000000190488b20 -[VKMapCameraController setYaw:animated:] + 100
9 MapKit 0x000000018540263c -[MKMapView snapToNorth:] + 148
before finally calling:
0 CoreFoundation 0x0000000183251e38 _CFArrayReplaceValues + 152
1 CoreFoundation 0x000000018332876c __CFRepositionTimerInMode + 108
2 CoreFoundation 0x000000018332876c __CFRepositionTimerInMode + 108
3 CoreFoundation 0x0000000183272630 CFRunLoopTimerSetNextFireDate + 580
4 MapKit 0x00000001853e8588 -[MKMapView _didChangeRegionMidstream:] + 196
5 MapKit 0x0000000185404e90 -[MKMapView mapLayer:didChangeRegionAnimated:] + 60
where _CGArrayReplaceValues crashes with a EXC_BAD_ACCESS KERN_PROTECTION_FAILURE at 0x000000016fccbef0 error.
I'd like to point out we never directly call any of the methods in this crash report, in fact VectorKit is completely private Apple framework. The only thing we ever do in the app remotely related is call basic setRegion:animated: methods, usually after a user taps an annotation to center on said annotation. It is also worth pointing out this only happens on iOS 8. Not a single iOS 7 crash has been reported.
Here is a link for full crash report: http://crashes.to/s/f09eb96c753
Any help is appreciated. Thank you.
Try enabling NSZombieEnabled. Once enabled, when an object reaches a retain count of 0, instead of being deallocated it'll morph itself into an NSZombie instance. When a zombie receives a message it will log a warning rather than crashing or behaving in an unpredictable way.
To be quite honest i'm not really sure why this is only crashing on iOS 8 and not iOS 7 but a EXC_BAD_ACCESS signal is the result of passing an invalid pointer to a system call, so you might be dereferencing a null pointer somewhere.
If the above NSZombieEnabled doesn't uncover the issue then try using the Static Analyzer.
I am experiencing an incredibly strange crash inside my override of the encodeWithCoder: method. You can see my implementation at https://github.com/reidmain/FDModel/blob/193b0661f7ab1ce62f80de02bcbfa10a38c58ce9/FDModel/FDModel.m#L340-358
I have received tens of thousands of crash logs similar to the following:
Exception Type: SIGSEGV
Exception Codes: SEGV_ACCERR at 0x5000000c
Crashed Thread: 0
Application Specific Information:
objc_msgSend() selector name: replacementObjectForKeyedArchiver:
Thread 0 Crashed:
0 libobjc.A.dylib 0x38acb626 objc_msgSend + 6
1 Foundation 0x2eca70d7 _encodeObject + 128
2 MyApp 0x00411d8b -[FDModel encodeWithCoder:] + 268
3 Foundation 0x2eca7479 _encodeObject + 1058
4 Foundation 0x2eca8657 -[NSKeyedArchiver _encodeArrayOfObjects:forKey:] + 396
5 Foundation 0x2eca8329 -[NSDictionary(NSDictionary) encodeWithCoder:] + 918
6 Foundation 0x2eca7479 _encodeObject + 1058
7 Foundation 0x2ecf432d +[NSKeyedArchiver archiveRootObject:toFile:] + 202
8 MyApp 0x003dd561 -[MyAppsDataClient _saveObjectsToDisk] + 74
The problem is that inside the company no one has experienced these crashes personally. Even after writing a stress test which calls the method which triggers the encoding every couple seconds and letting it run for an hour nothing happens.
It looks like either FDModel or the object that it is trying to encode is somehow released from memory but how this happens remains a mystery to me. If FDModel was released from memory how would _encodeObject succeed being called? If it was FDModel being released from memory I would expect to see a wide range of crash logs on all sorts of methods being called on FDModel but it not existing in memory. All of the crashes are complaining about replacementObjectForKeyedArchiver:
After talking with an Apple employee on the dev forums it looks like the issue was due to the model being encoded at the same time as it was being modified.
I updated FDModel to use a NSRecursiveLock whenever changes were being made the model or whenever the model was being encoded.
Normally the crash log indicates where this might be happening, but in this case, this is all I am getting. Lets say my main view is A and I have A,B, and C views.
This only happens if I do the following:
Go from A to B to C, go out of app and load up a few other apps. Then return to my app, go back to B, then go back to A (THIS IS WHERE IT CRASHES).
EDIT - I had posted the wrong thread before...here is the correct thread
CRASH LOG:
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x4daf03bd
Crashed Thread: 7
Thread 7 name: Dispatch queue: com.apple.root.default-priority
Thread 7 Crashed:
0 libobjc.A.dylib 0x36f22f78 objc_msgSend + 16
1 Foundation 0x33707d04 _NSDescriptionWithLocaleFunc + 44
2 CoreFoundation 0x34f3a96e __CFStringAppendFormatCore + 7998
3 CoreFoundation 0x34eb51d8 _CFStringCreateWithFormatAndArgumentsAux + 68
4 Foundation 0x33707c2e +[NSString stringWithFormat:] + 54
5 MyGreatApp 0x00061028 -[DataAccessor getProducts:div:productType:cat:searchsilver:completion:] (DataAccessor.m:301)
6 MyGreatApp 0x00017196 __36-[products showNationalCategories]_block_invoke_0 (products.m:1688)
7 libdispatch.dylib 0x37886c52 _dispatch_call_block_and_release + 6
8 libdispatch.dylib 0x378927b4 _dispatch_worker_thread2 + 256
9 libsystem_c.dylib 0x35b45df4 _pthread_wqthread + 288
10 libsystem_c.dylib 0x35b45cc8 start_wqthread + 0
Here is line 301 (Note, all the objects going into the string are NSStrings):
NSString *urlStr = [NSString stringWithFormat:#"%#?api_key=%#&device[duid]=%#&division=%#",apiUrl,apiKey, duid, division];
My wild guess is that something is being deallocated in viewDidUnload which is relied upon and not being re-initialized properly. In most cases, viewDidUnload does not get called while testing; and it's the one thing I can think might be happening while you are off in those other apps. Do some double-checking on all of A's properties which get used when the view comes on screen, and double-check that they are non-nil.
I think your callback is being run when a different view controller from the one you were expecting is being presented. I think its first best to work out the faulty string pointer by NSLogging them on separate code lines. Also have you used any _block decorations for those string parameters (or used them twice: both inside and outside the block) -- that would break the retain on them.
One of our testers is reporting the following crash:
0 APP_NAME_WAS_HERE 0x00074892 testflight_backtrace + 158
1 APP_NAME_WAS_HERE 0x000754bc TFSignalHandler + 244
2 libsystem_c.dylib 0x378ea7ec _sigtramp + 48
3 CoreFoundation 0x30ef42e6 CFRelease + 94
4 CoreFoundation 0x30f09a36 -[__NSArrayM removeObjectAtIndex:] + 294
5 CoreFoundation 0x30f4a65e -[NSMutableArray removeObjectsInRange:] + 90
6 APP_NAME_WAS_HERE 0x000570ca -[StoryViewController rewindToChunkIndex:] + 558
7 APP_NAME_WAS_HERE 0x00057396 -[StoryViewController restartChapter] + 22
Unfortunately, we can't reproduce the crash - we're only getting crash log sent through via TestFlight.
We did receive debug logs to confirm that the removeObjectsInRange is definitely receiving a valid range for the NSMutableArray that is being acted upon. (besides, that would kick up an exception rather than raising a signal, right?)
My only thought is that the object is getting a double release, but I'm not sure how this is possible with ARC switched on?
Note that the objects being removed are UIView subclasses, and before-hand, some or all of them may have been removed from their superviews. So I wouldn't be surprised if they were released at this stage, I just don't understand why that's causing it to crash!
EDIT: In an attempt to verify that it's an over-released object, I artificially tried over-releasing an object (using CFRelease(__bridge (CFTypeRef) obj) to force release in ARC environment) to see the type of crash log that it would produce. Unfortunately, it's a bit different, so perhaps it's not an over-release after all? Is it perhaps a scribble of some kind?
Here's what a definite over-release looks like:
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x00000000, 0x00000000
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x369c732c __pthread_kill + 8
1 libsystem_c.dylib 0x36c20208 pthread_kill + 48
2 libsystem_c.dylib 0x36c19298 abort + 88
3 libsystem_c.dylib 0x36bd437a free + 374
4 libobjc.A.dylib 0x375e4d72 object_dispose + 14
5 CoreFoundation 0x362e9618 -[NSObject dealloc] + 76
6 UIKit 0x310323a8 -[UIView dealloc] + 620
7 libobjc.A.dylib 0x375e416e _objc_rootRelease + 30
8 CoreFoundation 0x362dc2e0 CFRelease + 88
9 APP_NAME_WAS_HERE 0x000cea98 -[StoryViewController rewindToChunkIndex:] (StoryViewController.m:584)
Here's what an over-release crash log looks like:
If you look at the stack trace, the crash occurs not because of wrong index, but because of a over-release of the objects.
NSArray sends a retain message when you add an object and a release message when you remove an object. Apparently, that release is crashing.
This means, you are over-releasing the object you added to your array.
Update
Are your sub-views strongly owned? Is your ownership modifier "strong" or "weak" or unsafe_unretained? Even in ARC, there can be unbalanced calls to retain if you don't "own" your variables properly. For example, since you are manually adding and removing views into another array, you should "own" it. Remove from superview will send a release to the view and addSubview will send a retain. When you build your views using XIB, the XIB loading mechanism uses the property'w ownership modifier and bump up the retain count accordingly when it adds it to the view (StoryViewController.view). Since XIB loading mechanism added it to subviews, you shouldn't unload it. If you want to unload it, you should "own" it by changing the property type of your subviews (outlets) to "strong", otherwise, you will end up messing the ownership.
Start thinking in terms of Object graphs and who owns what, when you write your ARC ownership modifiers. ARC is not like Garbage collection. Things like this will still happen :)
My fix for the problem was to turn the compiler's optimization level down to None [-O0] from the default setting of Fastest, Smallest [-Os] in the target's build setting (set in release only).
I'm not sure whether it's simply sidestepping the problem or whether there's actually a bug in the compiler, but there you go. And it explains why only testers were getting it.
Without seeing code, it's tough to say what the real problem is. I'd bet its a case of something being over-released. Remember, ARC does not apply to Core Foundation objects.
It's possible that you've assigned a property with an convenience constructor instead of with alloc and init. Such objects are autoreleased and must be explicitly retained or they will be immediately deallocated in the following cycle.
I've been getting some low level crashes lately, and this one in particular is hard to determine the origin / state of the app. Has anyone seen this or know the problem? Thanks!
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x3dcccccd
Crashed Thread: 0
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x3dcccccd
Crashed Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x000025fa objc_msgSend + 18
1 UIKit 0x00162d1c -[UIAlertView(Private) _performPopup:] + 12
2 UIKit 0x001628de -[UIAlertView(Private) _repopup] + 10
3 UIKit 0x0016d196 -[UIAlertView(Private) _removeAlertWindowOrShowAnOldAlert] + 70
4 UIKit 0x00162afa -[UIAlertView(Private) _popoutAnimationDidStop:finished:] + 502
5 UIKit 0x00050ae4 -[UIViewAnimationState sendDelegateAnimationDidStop:finished:] + 184
6 UIKit 0x000509ee -[UIViewAnimationState animationDidStop:finished:] + 34
7 QuartzCore 0x0002ee8c run_animation_callbacks(double, void*) + 284
8 QuartzCore 0x0002ed2c CA::timer_callback(__CFRunLoopTimer*, void*) + 96
9 CoreFoundation 0x00022d1c CFRunLoopRunSpecific + 2092
10 CoreFoundation 0x000224da CFRunLoopRunInMode + 42
11 GraphicsServices 0x000030d4 GSEventRunModal + 108
12 GraphicsServices 0x00003180 GSEventRun + 56
13 UIKit 0x0000342a -[UIApplication _run] + 374
14 UIKit 0x00001954 UIApplicationMain + 636
15 iPadDrinkHub.1.0.7 0x00002f24 0x1000 + 7972
16 iPadDrinkHub.1.0.7 0x00002ed8 0x1000 + 7896
Weird crashes are sometimes a symptom of memory corruption and/or mismanagement. I just found and fixed a difficult-to-find bug in one of my apps a few days ago. The app had been working flawlessly for 6 months on iOS 3.2, but would crash instantly on iOS 4.2. The crash was happening while adding the main view to the window during applicationDidFinishLaunching. The stack trace showed 100% iOS code; there wasn't a single function of mine in there anywhere (except for applicationDidFinishLaunching). It turned out I was over-releasing a UIImage in code that had been called earlier while views were getting loaded. (I was mistakenly calling release on an autoreleased UIImage).
I haven't seen the specific crash that you're seeing, but here are a few things you can try that may shed some light:
(1) Run the app with NSZombieEnabled. This is an environment variable you set via Xcode that will often identify places where you may be referencing objects that have already been freed (e.g., like the over-release example I mentioned earlier). Additional details are here:
http://www.cocoadev.com/index.pl?NSZombieEnabled
(2) You can turn on logging that will log all messages sent to all objects. The log is a written to a text file in the tmp folder. If you inspect the log file leading up to the crash, you may gain some insight into what's happening right before the crash. This is actually the technique I used to solve my bug. You can either modify your code to enable/disable logging:
instrumentObjcMessageSends(YES);
// Do stuff...
instrumentObjcMessageSends(NO);
Or, you can call the function directly from the debugger. For example, set a breakpoint right before the crash, then drop into the debugger console and do this:
(gdb) call (void)instrumentObjcMessageSends(YES)
Additional details are here:
http://www.dribin.org/dave/blog/archives/2006/04/22/tracing_objc/