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.
Related
I'm seeing a few crash reports that say
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Termination Reason: TCC, This app has crashed because it attempted to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSPhotoLibraryAddUsageDescription key with a string value explaining to the user how the app uses this data.
All very interesting, especially because my app never goes anywhere near the photo library for any reason whatever. So what on earth is going on here, and what's TCC anyhow?
I'm perfectly willing to add this key, but I have no explanation for why it would be needed so I can't supply any meaningful text!
Problem arises in iOS 12.1 only, though that might not be meaningful data as you can't prove a negative. I suspect an iOS bug of course, and will report this, but I'm curious as to whether anyone else has seen this odd phenomenon.
Here's a bit more of a typical crash report:
Triggered by Thread: 3
[skipping thread 0 and 1]
Thread 2 name:
Thread 2:
0 libsystem_kernel.dylib 0x000000019ffe3f0c semaphore_wait_trap + 8
1 libdispatch.dylib 0x000000019fe32f8c _dispatch_sema4_wait$VARIANT$mp + 24 (lock.c:134)
2 libdispatch.dylib 0x000000019fe33a10 _dispatch_semaphore_wait_slow + 136 (semaphore.c:132)
3 AssetsLibraryServices 0x00000001ade2d140 __79-[PLPrivacy _isPhotosAccessAllowedWithScope:forceHandler:accessAllowedHandler:]_block_invoke_2 + 412 (PLPrivacy.m:183)
4 AssetsLibraryServices 0x00000001ade138b4 __pl_dispatch_async_block_invoke + 36 (PLDispatchHelpers.m:23)
[skipping the rest]
Thread 3 Crashed:
0 libsystem_kernel.dylib 0x000000019ffeddf8 __abort_with_payload + 8
1 libsystem_kernel.dylib 0x000000019ffe7838 abort_with_payload_wrapper_internal + 100 (terminate_with_reason.c:71)
2 libsystem_kernel.dylib 0x000000019ffe7868 abort_with_payload + 12 (terminate_with_reason.c:93)
3 TCC 0x00000001a32aea70 __CRASHING_DUE_TO_PRIVACY_VIOLATION__ + 204 (TCC.c:372)
4 TCC 0x00000001a32ae9a4 __TCCAccessRequest_block_invoke.77 + 708 (TCC.c:508)
5 TCC 0x00000001a32b2a90 __tccd_send_message_block_invoke + 276 (TCC.c:220)
[skipping the rest]
I was able to reproduce the crash! Here's the deal: my app contains a web view. If the user presses on an image in that web view, a Save menu item appears. If the user taps Save, we need permission; if there's no privacy string in the Info.plist, we crash at that moment (and if there is one, we get the authorization dialog).
In my opinion, this is an iOS bug. I never intended for the user to do this; it's just a feature of web views. The act of saving from the web view to the photos library is therefore effectively out of process; it's the user who is doing it, not my app. And the user should not need permission; it's the user who tapped on the image and who then tapped the Save button. There is no way this scenario could have happened without the user making multiple deliberate moves, none of which involve my app directly. I'll be reporting this to Apple.
I just received my first crash report from Crashlytics and am attempting to correct the issue. Unfortunately it is only with a line of code that runs on older devices so I can't test it on my iPhone 6.
The crash report from Crashlytics highlights two threads, the first reads:
Fatal Exception: NSInvalidArgumentException
-[CABasicAnimation altitude]: unrecognized selector sent to instance 0x17734440
While the second reads:
Crashed: Map Update :: NSOperation 0x1a839470
SIGABRT ABORT at 0x316a3dfc
The indicated line of code for both threads is:
let relativeAlt = mylocation.altitude - appDelegate.elevation
Where:
let mylocation = self.mapView.myLocation
let appDelegate = (UIApplication.sharedApplication().delegate as AppDelegate)
I'm trying to understand what I'm reading in the crash report. The way I see it the program doesn't understand the altitude reference made for some reason? This doesn't make sense to me since this crash seems to occur after that app has been running for several minutes without error, the highlighted line of code is run possibly hundreds of times before the app crashed. What is really happening here?
Additional Information:
Since writing, I have received additional crashes that I believe stem from the same issue:
Crashed: Map Update :: NSOperation 0x19fb2d50
EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x11d077ca
Crashed: Map Update :: NSOperation 0x145ced50
EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x81450a64
The first highlighted the following line in my code (I believe since I had worked on the app since this beta release and the line numbers have changed slightly):
self.lastLocation = (self.mapView.myLocation as CLLocation).coordinate
While the second crash just gave me:
libobjc.A.dylib
objc_msgSend + 5
The first of the new crashes (That provided a line of code) provided this report:
Thread : Crashed: Map Update :: NSOperation 0x19fb2d50
0 libobjc.A.dylib 0x3105c708 objc_release + 7
1 FlightTracker 0x000ba830 FlightTracker.MapViewController. (locationManager (FlightTracker.MapViewController) -> (Swift.ImplicitlyUnwrappedOptional<ObjectiveC.CLLocationManager>, didUpdateLocations : Swift.ImplicitlyUnwrappedOptional<Swift.Array<Swift.AnyObject>>) -> ()).(closure #1) (MapViewController.swift:168)
2 Foundation 0x244ce0fd __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 8
3 Foundation 0x24438fc5 -[NSBlockOperation main] + 148
4 Foundation 0x2442b845 -[__NSOperationInternal _start:] + 768
5 Foundation 0x244d0a57 __NSOQSchedule_f + 186
6 libdispatch.dylib 0x315ad5d9 _dispatch_queue_drain$VARIANT$mp + 948
7 libdispatch.dylib 0x315ad0a9 _dispatch_queue_invoke$VARIANT$mp + 84
8 libdispatch.dylib 0x315af0d3 _dispatch_root_queue_drain + 330
9 libdispatch.dylib 0x315b01fb _dispatch_worker_thread3 + 106
10 libsystem_pthread.dylib 0x31720e25 _pthread_wqthread + 668
Probably not your problem, but I just had a SIGABRT that was driving me nuts (that's how I ended up looking at this question) and I'll post my solution in case it helps some future S.O. spelunker.
In my (iPad, not that it matters) app, you can push a button that results in the creation of a not-full-screen UIViewController which contains a UITableView, and this viewController is presented via UIPopoverController.
In my case I had a screw-up in my loading of the tableView items which, at the time of creating the tableView cell I ended up trying to add a null value into a dictionary. (It's a long story, having to do with an infrastructure class that expects the data to be in a certain format.)
Anyway, attempting to access newViewController.view caused the SIGABRT on that line, with no clue that the problem was related to filling the tableView cell. Nothing tableView-related was evident in the stack trace, so it took me quite a while to narrow things down. I eventually just guessed "maybe it's the tableview" and disconnected the IBOutlet and delegate/dataSource to see if the crash went away.
...And it did. Which lead me down the path of finding the real problem.
Anyway, that's my story. Hope it's helpful to someone.
Due to the lack of a full/proper crash report and the lack of more code and architecture, the following is an assumption using the little bits of information that are available.
You are accessing a variable in a background thread (NSOperation queue) that got released on another thread and now isn't available any longer, so the pointer shows to some other random object in the memory. And that random object surely has no idea what to do with the altitude message which is then causing the crash.
You have to make sure that all variables used in the background thread, are available and not released in another thread.
Wow, I just had another "impossible to track down" solution to this that was driving me bonkers.
Earlier in the day, I'd done a major refactor as some of the objects in my game had names like RFCFoo and some were like RfcBar and I wanted to standardize the capitalization.
So I used XCode's Refactor->Rename... tool, and it worked great, except for one thing:
It failed to rename one specific .xib file, which remained as "RFCBlahBlah.xib" when I was trying to load it as "RfcBlahBlah.xib"
Again, I hope this proves useful for some future SO searcher.
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.
I intermittently get Crashlytics reports with the following error:
Crashed: com.apple.main-thread
EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x0000000e
raw
libobjc.A.dylib
objc_msgSend + 5
1
UIKit
-[UICollectionViewUpdate _computeItemUpdates] + 1588
2
UIKit
-[UICollectionViewUpdate initWithCollectionView:updateItems:oldModel:newModel:oldVisibleBounds:newVisibleBounds:] + 254
3
UIKit
-[UICollectionView _endItemAnimations] + 6904
4
UIKit
-[UICollectionView performBatchUpdates:completion:] + 386
How can I debug this? The crash appears to be internal to a UICollectionView. Does this mean the crash is internal to an Apple SDK?
You can add a symbolic breakpoint with -[UICollectionViewUpdate _computeItemUpdates] as the value. Whenever that method is called, you'll be able to navigate the stack trace and (hopefully) see which line of your code is the last to be called before the crash.
The downside of this approach is you'll probably get a lot of pauses that are not followed by the crash, but it'll give you an idea of where it's coming from. Once you find the source of the crash in your code, unset the breakpoint and change a value or set something related to the cells until you can cause the crash to happen.
This is generally my approach to tracking down crashes from my crash reports from Flurry. Being you've ask this question half a year ago, if you found a solution to tracking down these types of bugs, I would appreciate it if you shared :)
I am stuck with the following crash report:
Date/Time: 2013-09-12 22:39:54 +0000
OS Version: iPhone OS 6.1.3 (10B329)
Report Version: 104
Exception Type: SIGSEGV
Exception Codes: SEGV_ACCERR at 0xa0000008
Crashed Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x39a3c564 _cache_getImp + 4
1 libobjc.A.dylib 0x39a3e1d7 class_respondsToSelector + 31
2 CoreFoundation 0x31b96605 objectIsKindOfClass + 37
3 CoreFoundation 0x31b9635d __handleUncaughtException + 69
4 libobjc.A.dylib 0x39a41a65 _objc_terminate() + 129
5 libc++abi.dylib 0x3948e07b safe_handler_caller(void (*)()) + 79
6 libc++abi.dylib 0x3948e114 std::terminate() + 20
7 libc++abi.dylib 0x3948f599 __cxa_current_exception_type + 1
8 libobjc.A.dylib 0x39a419d1 objc_exception_rethrow + 13
9 CoreFoundation 0x31adcf21 CFRunLoopRunSpecific + 457
10 CoreFoundation 0x31adcd49 CFRunLoopRunInMode + 105
11 GraphicsServices 0x356a82eb GSEventRunModal + 75
12 UIKit 0x339f2301 UIApplicationMain + 1121
13 Our App 0x0003bc27 main (main.m:15)
After different attempts to fix the bug causing this error I keep receiving this crashlog again and again from PLCrashReporter (from our adhoc builds from the beta testers). The different exception codes vary from SIGSEGV/SEGV_ACCERR to SIGBUS/BUS_ADRALN to EXC_BAD_ACCESS/KERN_INVALID_ADDRESS
I am using the rapidjson library on iOS (armv7 and armv7s) with the padding fix as described here (#8) and I use the objective-c runtime functions to add method implementation on runtime (using class_addMethod).
Our codebase exists of mostly Objective-C code with some Obj-C++ and some C code. Memory Management is done by ARC except for the Obj-C++ and C parts which is handled manually. I looked into every malloc/free call and I extensively used libgmalloc to determine memory issues but there is nothing which does not seem correct to me.
I cannot reproduce this crashlogs myself, not in debug or release mode, but our beta testers keep sending me this crashlog once in a while (1 in about 50 runs). As our product (hopefully) will run on many iOS devices soon, this is not something we can left broken.
After reading a lot of memory management articles I suspect this issue is caused by bad memory alignment. Therefore I suspect rapidjson to be the cause of this bug. My lack of knowledge about memory alignment on iOS / armv7 does not allow me to fix this crashlog. Can someone explain me more about this subject on iOS? Or am I looking in the wrong place and is this another memory issue?
I hope someone can point me in the right direction.
If more info is needed I am happy to provide it.
Note: I am not looking for answers as using JSONKit or another library to replace rapidjson. Thanks :)
This issue was previously addressed here: https://devforums.apple.com/message/807860
In short, the original Objective-C exception has been released (eg, by an autorelease pool) prior to it being dereferenced in the uncaught exception handler. As such, __handleUncaughtException() dereferences a now-dead pointer, and you see the crash in your exception handler.
First, the address 0xa0000008 does not look misaligned, and SEGV_ACCERR does not mean an alignment problem, but a memory access permission problem (from sys/signal.h):
#define SEGV_ACCERR 2 /* [XSI] invalid permission for mapped object */
Considering you are using class_addMethod() and the crash is in _cache_getImp(), which is part of retrieving a method, my largely unfounded suspicion would be that you passed some invalid pointers to class_addMethod(), or overwrote that information later on.
Something to check would be whether you are using either globals or malloc()ed memory, because the runtime functions do not make copies for you.
Second, the crash you are seeing is secondary, you are crashing while running the top-level exception handler that is already terminating (_objc_terminate()) your program from an earlier exception, but in this case it's not a Unix signal, but an Objective-C exception: objc_exception_rethrow().
So you probably need to figure out that primary error first, for example from logs of the exception (just a backtrace isn't enough in many cases).