After all long break from blogging I figure I’d get back into the habit again..
& what better way to do so then beginning a new series on iPhone development. Over the next few months I’ll try to keep the blog up to date with useful tips & tricks I’ve picked up along the way. Hope it helps someone out!!
After wrestling furiously with xcode over the past several months I bumped into a few useful tid-bits that might help with debugging. I would like to vent about the god-awful nature of the IDE & how much it makes me want to boil a pet in anger but I wont. I will say one thing though; boy have I learnt to appreciate the joys of Visual Studio & programming in a Windows environment (VS2008 + Visual Assist + RockScroll = WIN). Now to the topic at hand:-
I ran into one of these babies recently & after surfing the net for some info on the subject it looks like it’s the result of a signal sent from an active thread which hung on trying to release memory that has already been released (or something like that..). Now the great thing about this error is you don’t get any call stack or console output to tell you where things when kabloom but thankfully there are a few things you can try to in order to isolate the problem..
- Good ‘ol process of elimination – whittle down the last several code changes you made until you can home-in on the section of code that’s causing the problems. Not a great solution I know.. That’s why you should really try the next options:-
- Set the NSZombieEnabled environment variable (with the value of “YES”) in your executable – this will leave dummy object references around so when the system dies you can get a useful stack trace to the problem. You can set this by right clicking on your executable and navigating to the “Arguements” section of the “Get Info” page. Use the plus icon to add a new environment variable & set the value accordingly. Also make sure the check box is ticked so that it’s active when you deploy. Personally I’ve found that this works fine provided the problem lives somewhere in your Obj-C code using any of the Cocoa frameworks but for me, the first time I encountered this issue it was hiding somewhere in my own C++ library code & thus I ended up trying the next solution:-
- Use Guard Malloc – This is a great little option that can catch invalid access crashes immediately as they occur but bear in mind it WILL slow down your application considerably when used. You can enable/disable it in the Run menu for xcode & then just run the app, get it to crash & it’ll take you directly to the call stack item which killed your flOw. Just make sure to disable it when you’re done otherwise you’ll end up worrying about where all that performance went..
Hope some of these tid-bits can be of use to someone & I’ll be posting more useful stabs of info as I continue my adventures in the land of iPhone development hades..
– The Hog