I'm trying to debug an EXC_BAD_ACCESS crash using NSZombie. My app creates lots of large objects though and with NSZombie enabled they aren't getting released causing the app to crash in seconds. This means I can't even cause the EXC_BAD_ACCESS crash before the app crashes due to low memory.
Is there an alternative? Can I enable NSZombie on specific file instead of the entire project? How else could I debug this crash (I know it's caused by UIGestureRecognizer but I use them a lot so it doesn't narrow down the issue significantly).
Thanks.
Edit:
Thanks for the advice. I think I may have solved the issue and will report back after more testing.
Edit 2: Sovled the issue myself but selected the answer which seems like it would be a good solution to any similar issues in the future.
All I can think of is implementing it manually; create a proxy container that holds an object of type id and nominates that as -forwardingTargetForSelector: as well as getting it to respond to -isKindOfClass:, etc.
Disable ARC for the proxy and have it retain itself during init and check its own retainCount when nominating a forwarding target.
If the count is 1 then raise an exception or log a warning or whatever.
Have suspect classes wrap themselves in and return a proxy as the last line of their unit.
For possible bonus points, store [NSThread callStackSymbols] somewhere (probably on disk) during the proxy's unit so you can at least find out where the incorrectly managed object was created.
NSZombies was/is for apps that use their own memory management. If your app uses ARC then this won't help.
Create a new Breakpoint: All Exceptions
That should usually show you where you trigger the bad access.
Related
I am facing this weird random crash where I get EXC_BAD_ACCESS on an object that exists. I am totally stumped on why this is happening. The code in the image executes without any issues 99.99% of the time. I saw this crash second time and that when I thought I should figure out what might be going wrong. I am executing this code on the main thread and the crash line has two core data objects. This shouldn't be a concurrency issue because it's only used in this class. Scary part is that object is there, values are there, still, I am getting EXC_BAD_ACCESS. Any ideas why this might be happening?
Let me know if you guys need more info. And thanks in advance for your help. :)
EDIT 1
Definition of Employee and EmployeeForTask (the class declarations are empty and has no variable defined in it, it just inherits from NSManagedObject)
You should enable NSZombies. Zombies helps to detect these kind of crashes by logging problem in console. you can enable zombies by :Click on Product⇒Edit Scheme to open the sheet and set the Enable Zombie Objects check box
When building app on real device then disable Zombies. Otherwise app will not run on device.
From time to time, Xcode Crashes comes up with a crash that i cannot understand. I pasted the xccrashpoint to gist
It states, that Thread 12 crashed somewhere in CoreGraphics called by CorePDF, called by QuartzCore drawing some layers. This seems like OS-called code, maybe via thread 1 which is doing _saveSnapshotWithName. So i assume, that this happens when closing the app.
Does anyone have at least a rough idea what is going on here? Maybe someone saw something similar before and can give a hint about what is crashing…
There is nothing special in the app that would cause dramatically wrong behaviour when leaving the app (-> when a screenshot ist taken).
Exec bad errors occur when an attempt is made to access a object or memory location which is not yet initialized.
There might be a problem with an object which you are not defining global.
Check if there is any object you defining and initializing in a method and trying to access out of the scope.
For more details related to errors and crashes, please go through below link.
http://www.raywenderlich.com/10209/my-app-crashed-now-what-part-1
Testing my app which gets location data from an api and displays in a table view. Was testing something else today and app crashed - EXC_BAD_ACCESS (code=1, address=0X0). What does this mean and how do I read the information provided by Xcode to figure out how to fix?
EXEC_BAD_ACCESS usually means that you are trying to access an object which is not in memory or probably not properly initialized.
Check in your code,
if you are accessing your Dictionary variable after it is somehow removed?
is your variable properly initialized? You might have declared the variable but did not initialize it and accessing it.
There could be a ton of reasons and cant say much without seeing any code.
Try to turn on NSZombieOjects - this might provide you more debug information. Refer to here How to enable NSZombie in Xcode?
IF you would like to know where and when exactly is the error occurring, you could check for memory leaks using instruments. This might be helpful http://www.raywenderlich.com/2696/instruments-tutorial-for-ios-how-to-debug-memory-leaks
Based on the information you provided. My guess is that the library is calling out to a block you provided. Inside that block is a Dictionary which has something wrong with it.
Good luck!
If you were developing an iOS app using Xcode and were testing it on different devices, is there any reason as to why it would act differently given that the devices are the same model and have the same software version?
For example, I'd recently been working on an app. A clean build of that app were put on two different iPhone5s. (Same software version)
However while running on one of the phones I'd get a memory deallocation error similar to the following:
*** -[CFString release]: message sent to deallocated instance
Where as on the other device, no such error would appear.
Are there any obvious reasons as to why this might be the case for any app?
Your code probably isn't acting differently on the different devices. The problem most likely exists on all your devices, but will only cause a problem in certain circumstances. You can not predict when objects in the autorelease pool get deallocated, but you can be sure that it's not always going to be with the same timing. Running on different devices, timing of the draining of the autorelease pool can be different due to other background processes, memory usage, etc.
The deallocation error that you are seeing is most likely due to a release call you do on an autoreleased object, that you did not call retain on yourself. Check you code for objects that your create without an init call, but where you are calling release on. Also, try running your code in Instruments with enable Zombie Objects to see if you can find the NSString object that is causing the problem.
Your String is being under-retained or released.This problem occurs when you are trying to access the deallocated object. May be your string get released before you accessing it.I've face this problem.
Run your app in Instruments using the Zombies template. That will show you what object had the memory issue, and will let you see the entire retain/release history of that object. That should point you in the right direction.
For Zombies enable
option+cmnd+r
and then select Enable Zombie Objects and then Run.
Having a hard time tracking down a crash in an iPad application. The difficulty really stems from the fact that there is no errors or stack trace present when the application fails. It simply goes away like Keiser Soze, "And like that, poof. He's gone.".
I've replicated the crash on both the simulator and the device. There are zero device logs, nothing in the console, etc.
I know that during the crash some CoreGraphics operations are occurring in a background thread. Typically, three or so NSOperations are kicking of some image blends.
The blending consists of CGContext* calls (DrawImage, SetBlendMode, SetAlpha, etc). The NSOperation calls back to a delegate in the main thread to handle the image and set it to UIImage, so it shouldn't be a UI main thread conflict, but I'm not discounting anything at this point.
Are there some Xcode tricks I'm missing to track down exactly what is happening? Or at least get a better hint of where the problem lies?
EDIT I have run the app in Instruments tracking memory usage and see that it is pretty rock steady around 2MB. So, don't think it's a memory issue. But after consideration, this rock steady 2MB seems abnormally low. Is there a chance Instruments is not picking up the CoreGraphics allocations?
Try reading the registers.
Whenever my app crashes without error, in most cases I have found the exception in the registers.
First go to Exceptions tab and 'Add Exception Breakpoint' using the + at the bottom left corner.
Then when the app crashes click on "0 objc_exception_throw" under Thread 1
Finally in the console enter:
register read
(you should get a list of registers)
po $rax (normally the exception is in 'rax')
(you should see the exception output on the console)
Hope this helps.
For lack of a better solution, and if it isn't obvious, pepper your app with NSLogs to circle where this occurs, then drill deeper from there via breakpoints and/or additional logs.
Super late answer, but I've found that using try/catch helps give information when I can't get a stack trace and my application pulls a Keiser Soze.
#try
{
// suspected code causing crash/errors
}
#catch (NSException *exception)
{
NSLog(#"Exception: %#", exception);
}
In my case, it was because of bad outlet connection in the storyboard.
Check using breakpoint if viewDidLoad method of UIViewController to be loaded gets called. If not, check your outlet connections in the storyboard.
Incorrect connection crashes the app without any error or stack trace.
I am wondering what happened to the this class is not key value coding-compliant for the key error that used to show in older versions of XCode.
In my case, it was because I had "Zombie Objects" enabled in the scheme to help find the problem, which was eventually causing it to run out of memory and crash.
In my case it was due to an object being released. Normally it would say message sent to deallocated instance or something like that, but it didn't. I checked the iPhone's logs and found this: KERN_INVALID_ADDRESS, which I googled and came across this: KERN_INVALID_ADDRESS
Enabled zombie objects and found that I tried to use a deallocated instance. It also told me what object it was in the logs afterwards.
Hope it helps for future visitors.