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).
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 am writing an App using the Appcelerator framework, and I get occasional crashes. I'm trying to track down whats causing the crash, so I decided to take a look at the iOS simulator crash report. Its of course all greek to me, but was hoping for some guidance on what part of this is a clue to the cause of the crash?
I pulled out the thread which is labeled as 'Crashed', but within that thread there are multiple entries (0-9), listed below. Is there any clue to figuring out which of those entries is causing the problem?
Crashed Thread: 2 KrollContext<kroll$1>
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000bbadbeef
Thread 2 Crashed:: KrollContext<kroll$1>
0 com.a 0x000000010082865e Ti_WTFCrash + 62
1 com.a 0x000000010069ffe9 TiObjectGetProperty + 361
2 com.a 0x00000001002c42e5 -[KrollObject objectForTiString:context:] + 101
3 com.a 0x00000001002bf6a5 KrollGetProperty + 165
4 com.a 0x0000000100656ef7 TI::JSCallbackObject<TI::JSDestructibleObject>::getOwnPropertySlot(TI::JSObject*, TI::ExecState*, TI::PropertyName, TI::PropertySlot&) + 487
5 com.a 0x00000001005e32aa TI::TiValue::get(TI::ExecState*, TI::PropertyName, TI::PropertySlot&) const + 362
6 com.a 0x00000001006f6ec0 llint_slow_path_get_by_id + 192
7 com.a 0x0000000100701711 llint_op_get_by_id + 98
8 com.a 0x0000000100703ae2 llint_op_call + 153
9 com.a 0x00000001006ffea5 callToJavaScript + 191
SIGSEGV errors occur when you try to use an object that already has been garbage collected. It's the equivalent of NullPointer errors on Android.
Seeing it has callToJavaScript as well would mean a native event or callback is not finding the JavaScript object anymore.
I'd advise to use the Appcelerator Studio debugger and step through the code to the moment it crashes.
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 getting a crash in the app with the following stack trace-
Thread : Crashed: com.apple.main-thread
0 libobjc.A.dylib 0x39dfa66a objc_release + 9
1 libobjc.A.dylib 0x39dfb0d7 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 358
2 CoreFoundation 0x2f4a6c69 _CFAutoreleasePoolPop + 16
3 CoreFoundation 0x2f53c1cb __CFRunLoopRun + 1306
4 CoreFoundation 0x2f4a6f0f CFRunLoopRunSpecific + 522
5 CoreFoundation 0x2f4a6cf3 CFRunLoopRunInMode + 106
6 GraphicsServices 0x343ff663 GSEventRunModal + 138
7 UIKit 0x31df216d UIApplicationMain + 1136
8 Batted 0x0009db07 main (main.m:16)
The crash occurs when zombies are not enabled in the Scheme's diagnostics options. However, when I enabled it the crash doesn't occur.
I have read some of the other Q&A regarding this, and all of them seem to advice that once this behavior is seen, enable the zombies and run the Zombie Profile Instruments on the Simulator.
I tried that, but Instruments doesn't seem to indicate anything wrong and the app works.
Any clue to what else can be done here to root-cause this issue?
I am using XCode 5.1 with iOS 7.1 in Simulator.
UPDATE 1
Found the offending code causing the problem but I am still not sure why it is causing the problem.
I am using CoreData, and in subclass of the NSManagedObject, I have -
- (void)willTurnIntoFault;
{
[super willTurnIntoFault];
if ([self observationInfo])
{
BNLogInfo(#"%# has observers:\n%#", [self objectID], [self observationInfo]);
}
}
In the above code, [self observationInfo] is the offending line.
When the app starts up, I loop over some of the NSManagedObjects in an enumeration block and set some property on it, which in turn fires the willTurnIntoFault method. Once the enumeration block completes, the crash happens.
The mystery is that the crash doesn't happen inside this method, but without this method subclassed everything runs fine.
The Q&As say to enable zombies (or run under the Zombies instrument) because a zombie often causes this sort of error.
But it's not the only cause.
Your program is corrupting the heap. Most likely it's overwriting the isa pointer (the class pointer) in some object that's in the autorelease pool, so when the run loop drains the autorelease pool, objc_release tries to dereference the bogus isa pointer and crashes.
Enabling zombies can mask an error like this because, with zombies, the runtime never actually frees objects. This means you end up with lots of parts of the heap that don't get used (unless you try to send a message to a zombie), so they never cause trouble if you corrupt them.
These sorts of crashes can be very difficult to debug, but there's a tool called “guard malloc” that sometimes helps. From the menu bar, choose Product > Scheme > Edit Scheme. Click the Run action in the list on the left. Then click the Diagnostics tab. Turn on the “Enable Guard Malloc” option. Then try to reproduce the crash. Guard malloc will detect certain types of heap corruption immediately and stop the program on the corrupting instruction.
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.