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.
Related
I only see this crash in Xcode > Window > Organizer > Crashes tab and not in Firebase Crashlytics.
It seems like it's only happening on iOS 13 so far and is one of the top 5 crashes in the app.
Also filed this in https://feedbackassistant.apple.com
I contacted Apple Developer support about this and got this answer:
In regards to what is happening in your crash logs, you definitely have a deallocated Zombie object that is being called causing this to crash. Notice the crashing thread in each of logs ends with Objective-C sending a message resulting in a EXC_BAD_ACCESS exception type.
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000010
Thread 0 name:
Thread 0 Crashed:
0 libobjc.A.dylib 0x00000001b6338fb0 objc_msgSend + 16
1 Foundation 0x00000001b69eb558 probeGC + 124 (NSMapTable.m:721)
2 Foundation 0x00000001b68fa2fc -[NSConcreteMapTable rehashAround:] + 208 (NSMapTable.m:1098)
3 Foundation 0x00000001b68fa1fc -[NSConcreteMapTable removeObjectForKey:] + 252 (NSMapTable.m:1141)
The crash signature that you are seeing is consistent with other known crash signatures I am tracking right now:
2 Foundation 0x00000001ad188d64 -[NSConcreteMapTable rehashAround:] + 204 (NSMapTable.m:1098)
3 Foundation 0x00000001ad188c68 -[NSConcreteMapTable removeObjectForKey:] + 248 (NSMapTable.m:1141)
4 UIKitCore 0x00000001b13d9484 _UIAnalyticsGatherMultitouchAnalytics + 632 (_UIMultitouchAnalytics.m:249)
I did some internal research on this issue and this is a bug right now in UIKit. Other applications are experiencing the same thing so please make sure to list as much information as possible in the bug report.
However, I don’t have any other information than what I see through apples bug reports.
Just two things I noticed:
This crash did so far occur under iOS 13.3.1 only.
This crash does not seem to be completely random, several crashes have the same reporter ID, so they are coming from the same user. This might mean that some setting their devices makes the crash more likely.
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
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.
We have crashes in our Unity iOS app.
We cannot reproduce them when debugging, but we regularly catch this crash.
We tried to analyze crash logs. (crash log is in the bottom of the post)
We examine part of code mentioned in crash log (m_Controller... methods), and cant see something that could cause crash.
We tried to imagine situations that can occurs in that part of code, but see nothing that can lead to crash. There are small* array of strings which is loadaed from disk, and modified.
We thinking of rewriting this part of code, but we afraid that otherp part of program can affect and lead to this crash, and that crash will remain after rewriting.
We tried to add try-catch block in this part of code and process situation when exception occurs gracefully (move user to our app's main menu), but we have to remove this block due to requirements
to our app.
Also, I think that crash occurs only (or at least much more frequent) in Ad-hoc build (which uses Release configuration in Xcode).
In parts of crash logs you can see mono_gc_out_of_memory in GC_malloc, which is looking very strange to me (I thought that iOS generates memory warning when memory is low, but possibly mono has its own constraints)
Also, there is another one or two crashes in this part of code with different crash logs (without mono_gc_out_of_memory, but ), but all of them occurs in methods of ArrayList ( ArrayList.Clear() in other situations).
Can you help us with this situation?
Can you give us any advice please on how should we deal with this crashes?
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x00000000e7ffdefe
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 MyApp 0x00f0e150 CrashedCheckBellowForHintsWhy() (CrashReporter.mm:73)
1 MyApp 0x00dcd888 m_wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr + 200
2 MyApp 0x01462eec mono_jit_runtime_invoke + 2152
3 MyApp 0x01504f24 mono_runtime_invoke + 132
4 MyApp 0x015050a8 mono_runtime_delegate_invoke + 128
5 MyApp 0x0150931c call_unhandled_exception_delegate + 340
6 MyApp 0x0150b230 mono_unhandled_exception + 328
7 MyApp 0x01473080 mono_handle_exception_internal + 952
8 MyApp 0x01473918 mono_handle_exception + 64
9 MyApp 0x0148f6d8 mono_arm_throw_exception + 184
10 MyApp 0x00e76ecc throw_exception + 44
11 MyApp 0x014b7f44 mono_gc_out_of_memory + 16
12 MyApp 0x0156a62c GC_generic_malloc + 452
13 MyApp 0x0156a6cc GC_malloc + 140
14 MyApp 0x015045fc mono_array_new_specific + 272
15 MyApp 0x00dd27ac m_wrapper_managed_to_native_object___icall_wrapper_mono_array_new_specific_intptr_int + 68
16 MyApp 0x00b7b2b8 m_System_Collections_ArrayList_InsertRange_int_System_Collections_ICollection + 212
17 MyApp 0x00b7b898 m_System_Collections_ArrayList_AddRange_System_Collections_ICollection + 52
18 MyApp 0x001fc3fc m_Controller_PrepareSkins_string_string_string_string_string_string_string__ + 1600
19 MyApp 0x001fda88 m_Controller_Awake + 4972
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/