I am seeing EXC_BAD_ACCESS KERN_INVALID_ADDRESS for class method.
From what I understand, I should not be seeing this for class/static methods.
Am I missing something?
Stack Trace:
Thread : Crashed: com.apple.root.user-initiated-qos
0 libobjc.A.dylib 0x0000000196eac0b4 objc_retain + 20
1 $APP_NAME 0x00000001002611a8 +[$CLASS_NAME $METHOD_NAME:] ($CLASS_NAME.m:590)
2 libdispatch.dylib 0x0000000197511994 _dispatch_call_block_and_release + 24
3 libdispatch.dylib 0x0000000197511954 _dispatch_client_callout + 16
4 libdispatch.dylib 0x000000019751e780 _dispatch_root_queue_drain + 1848
5 libdispatch.dylib 0x000000019751fc4c _dispatch_worker_thread3 + 108
6 libsystem_pthread.dylib 0x00000001976f121c _pthread_wqthread + 816
7 libsystem_pthread.dylib 0x00000001976f0ee0 start_wqthread + 4
I have seen this crash a few times (with very similar, if not identical stack traces), and found that it had to do with a nonatomic property being set with a new object, while simultaneously being read.
That objc_retain +20 instruction turned out to be a call on the isa property of the object being read-- but at that point the object is already released and the isa pointer is changed to a bad address
I was able to debug my issue by following this blog post by Mike Ash:
https://www.mikeash.com/pyblog/tales-from-the-crash-mines-issue-1.html
I would highly recommend reading the entire thing through-- it involves using the disassembler to debug, but it was definitely a lifesaver for us on multiple occasions
EDIT: Note that I am definitely not even 50% sure that this is your issue, but I hope that my anecdotal experience could save you some time. I know that I've spent many work weeks debugging issues that looked like this, but I still was never 100%
This crash happen because of dangling pointer.
For example, when variables or objects is trying to access an object that's already been de-allocated.
P.S: Most people might be confused about "memory leak" and "dangling pointer"
Dangling pointer occurs when a pointer references memory that has been de-allocated.
Memory Leak occurs when memory is still allocated but nothing references it.
EXC_BAD_ACCESS generally means that you are sending a objective C message to an invalid memory address.
It may cause:
1. An object that you want to use which has been deallocated.
2. When any variable or object is trying to access restricted memory. That means such crash occurs due to memory leak.
Related
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
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 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.
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).
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.