Seriously, we're arguing about this ?
If you want a total hack, just assign (id) 0x1 to any variable that
... please step away from the tequila.
I have a radical suggestion:
Test your software.
Like crazy talk!!
The detection of this class of bugs is extraordinarily easy to
automate, so my sympathy is lower than its usual nonexistence.
Here are the environment variables to set:
export NSZombieEnabled=YES
export CFZombieLevel=9
export MallocScribble=1
export MallocPreScribble=1
export MallocGuardEdges=1
You don't have to remember to run with these flags. Because, of
course, you have unit tests to at least provide some basic code
coverage.
If you don't, you really need to stop and fix that first. I can't
say I enjoy it, but begrudgingly, the results and ROI from unit tests
have been extremely impressive. Compared to the previous project I
worked on (no unit tests), we've been able to make much more
aggressive changes, and innovate faster, on my current project
entirely due to the unit testing infrastructure.
And then, you find an old mac mini or imac, and set up a cronjob to
run your unit tests every night. Once you have nightly unit tests
set up, running them again with different env flags is effortless.
If you're wondering wtf CFZombieLevel 9 does, check out Most Awesome
TechNote Ever:
<http://developer.apple.com/technotes/tn2004/tn2124.html>
Also, for more paranoia (at 100x slower), you can use (do NOT mix
with the above):
export DYLD_INSERT_LIBRARIES=/usr/lib/libgmalloc.dylib
export MALLOC_FILL_SPACE=1
Since those two modes behave differently, we run both nightly.
And while we're on this subject, there's another class of bugs that
nightly testing can really help with: leaks.
There are two easy leak tools to use via scripts. 'leaks' and
'heap'. Leaks is a good first pass, which rarely has false
positives, but very often has false negatives. Nevertheless, if your
code can't pass through leaks, you have a pretty big problem. So
'heap' fills in the gap to catch the leaks that 'leaks' missed.
To use 'heap' to catch leaks, you'll want to create a black list.
For example, in Core Data, after each unit test, we grep through the
heap result to see if there are any NSManaged*, NSEntity*, etc etc.
We skip over stuff that's hard to sort through, like NSString, but we
can at least ensure that none of our classes are still present in the
heap. That's a pretty thorough leak detection.
This is a bit harder than zombies, because you'll need to white list
known problems (in other people's code), and for the heap tool create
a custom black list. But this is absolutely worth the effort.
Running unit tests through debugging tools (zombies, leaks, etc)
nightly has been the single highest return on effort debugging
decisions I've ever seen.
Ever. Seen.
The second highest was actually writing the unit tests in the first
place, a necessary prerequisite, but more effort.
Just imagine what you could do mixing this stuff with dtrace ...
--
-Ben
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
