I have a crash that is happening deep within UIKit for some reason; an EXC_BAD_ACCESS error is happening something like 8 calls deep into a dismissModalViewController call. I tried enabling NSZombieEnabled for my executable, but the console log prints the same error regardless of whether or not zombies are turned on and i don't know which object is causing the issue. Is there something i'm missing that i need to do to get the console to print the correct information?
views:
324answers:
3
A:
Sounds like something is over-released in your Modal View Controller. Start by commenting out newish lines until it stops breaking.
coneybeare
2009-10-27 18:34:18
I know, but that doesn't answer the question of why NSZombieEnabled doesn't work as advertised which would make debugging much simpler.
Kevlar
2009-10-27 18:37:56
Randomly commenting out "newish" lines is a terribly inefficient way to go about debugging this.
nall
2009-10-27 19:00:27
Maybe for you, but for how I write my code (less is more), it is quite efficient.
coneybeare
2009-10-27 19:20:04
Regardless of coding style crashes are best debugged in the debugger. Not by guessing what might be causing the problem.
nall
2009-10-27 19:26:45
Ya... sorry but you are wrong. In the absence of any useful knowledge from the debugger, this way is very effective. If he only has a crash at his certain place, and there is only a few things he added to the controller until he noticed it breaking, it is not very difficult to comment out the few lines. It is a pain in the ass to trace these down when NSZombieEnabled does not give any useful info. I find them every time in less than 5 minutes by code-inspection/commenting out what I did last.
coneybeare
2009-10-27 20:22:12
And when the EXC_BAD_ACCESS isn't the result of a retain/release issue?
nall
2009-10-27 21:26:41
Then you can find the point where you are calling a memory location that is not allocated. We could go on like this all day… You have your way and I have mine. Good luck with finding an EXC_BAD_ACCESS, with no NSZombie information, any faster than this.
coneybeare
2009-10-27 23:32:56
Nowhere did I say that you shouldn't use NSZombies. They're terribly useful. I just don't like guessing when gdb+malloc_history gets me what I want without it.
nall
2009-10-28 01:30:53
@coneybeare, your method of debugging is not unlike fixing a car that won't start by swapping out all relevant parts one by one. Even mechanics use tools to help them diagnose where the real issue is. There's always some level of guesswork involved with debugging, but it shouldn't all be trial-and-error.
dreamlax
2009-10-28 20:35:28
Its simple: I add a few lines or functionality, I build and run, I test. If something breaks, AND THERE IS NO OTHER USEFUL INFORMATION LIKE THE OP SAID, then I look at my code that I just added and if I can't see where the problem lies, then comment out some of that until I find it. The OP even said himself: "luckily some educated guessing allowed me to fix the problem."You guys are all pretentious pricks if you can say you have never done this to find a hard bug. Get off my back
coneybeare
2009-10-28 20:58:33
+1
A:
Read about using Zombies here.
Run this in gdb. When you get the EXC_BAD_ACCESS look at the stack at that point (use gdb's where command or run the Xcode GUI debugger). If you are still having issues, post the stack in your original question.
Also zombies will only help you if you're dealing with NSObjects. If you're using low level malloc/free routines zombies buy you nothing for those allocations.
nall
2009-10-27 18:59:31
Your last statement was probably the case. It was something tripping up in the Core Animation code that crashed because some prior actions in the app would stop any animations from happening; luckily some educated guessing allowed me to fix the problem.
Kevlar
2009-10-28 15:41:45
The link named 'here' in @nall's post leads to a CocoaDev page which has been around forever. Which is not necessarily bad in the world of UNIX, but be weary of copying the ~/.gdbinit settings that AdhamhFindlay so thoughtfully provides. I did that, somewhere around Xcode 2.2, at which time they seemed to do no harm and very little good, but I've since removed them. If you feel the need to change any gdb settings, use Xcode's Target Info >> Build settings to do so. As far as NSZombieEnabled is concerned, it often seems to me to be as useful as the creatures it is named after.
Elise van Looij
2010-01-04 15:26:07
What's the rationale for not using .gdbinit? Putting settings solely in Xcode prevents gdb from respecting those when running outside of Xcode (which I happen to often do)
nall
2010-01-04 15:35:36
+1
A:
One thing I learned last weekend when NSZombieEnabled didn't seem to be working at all - make sure you're not passing in a non-object to some code.
In my case, I was returning an NSString as just "string" instead of @"string". That meant I was overwriting an NSString object with the c-string. When I later tried to write a new value in that object I was getting a BAD_ACCESS. NSZombie's couldn't help b/c it was not an object I was trying to overwrite, but that c-string.
As an aside, treat all warnings as errors in XCode - wish I could make them show up in RED in the IDE GUI - they are easy to miss sometimes.
Jason
2009-10-28 20:31:08
The next best thing to making them show up in RED is checking "Treat Warnings as Errors" in the Build section of the Target Info.
Elise van Looij
2010-01-04 15:14:42