[geeks] Glowing Review: Rational Purify

[Jonathan C. Patschke]

Rational Purify is some really astonishing software.  I pointed it at a
non-trivial[0] application I wrote for work, and it pointed out (within
a few seconds) six memory bugs that were causing intermittent crashes
after the application had been running for a few days.  They were really
subtle bugs, too.  A couple were mixing various memory allocation APIs
in slightly incompatible ways.  One was going through a linked-list and
accidentally hitting the iterator twice occasionally.  One was a classic
stack-smash that happened in a function that handled function pointers
and just happened to put something reasonable into the return
address...most of the time.

Its output is sane and reasonable.  Generally, it says "you tried to do
$thing here: (source file, line, code snippet, and several layers of
stack) with memory that you obtained here: (source file, line, code
snippet, and several layers of stack), and you can't do that because of
$reason".  After the app closes, it tells you all the allocations you
forgot to free.

It also catches the standard sorts of things you'd expect a memory
debugger to pick out: use of uninitialized storage, overrunning storage
bounds, double-frees, etc.  It ties in -very well- with the compiler
toolchain (at least, on Windows and Linux).  I just can't say anything
bad about it, aside from it being IBM-expensive.

I tried to find these bugs with Microsoft's debugger in Visual Studio
2005.  That debugger is one of the nicest things I've ever seen in an
IDE, but it gets really confused when Bad Things happen to the heap.  It
also doesn't manage multiple threads very well at all--if one of your
threads is blocked on a waitable object when the JIT debugger gets
triggered, the debugger never fully initializes.  It's an okay debugger.
Really, it's a great debugger, but it's a bit crap for finding creepy
memory bugs where the bogosity of the event takes place over a long
period of time.

Bear in mind that I don't normally code with the debugger in mind.  I've
been doing C for about 14 years.  I -like- managing memory by hand, and
I'm pretty good at it.  Usually, I debug with printfs (or my platform's
local equivalent) because I can usually find my defects -faster- that
way than with the debugger, but Purify is something else.  It's is like
having a magic wand to point at my software to find out why it's
crashing.  One of the things it pointed out was even something that was
preventing[1] me from running the application after it was built with
optimization turned on.

If you write code for a living and can afford $830 (for Win32, $2620 for
Unix), the amount of time this tool will save you is incredible.

Disclaimer: I don't work for IBM or own any IBM stock, but I do miss
running AIX on POWER.


[0] Multiple threads, high-resolution timers, uses native Win32 APIs
     plus NSPR plus the "legacy" ANSI C API, has a mix of C and C++ code
     with differing calling conventions, does tons of I/O over USB, and
     pounds the snot out of the display via GDI and GDI+ to keep the
     operator well-informed.
[1] The application would come up, run for a few seconds, and crash,
     always in a different spot.  Turn off the optimizer, and it runs for
     days.  Annoying, that, since VC++ won't let you compile in useful
     runtime memory-checking for code that's been run through the
     optimizer.
-- 
Jonathan Patschke | "There is more to life than increasing its speed."
Elgin, TX         |                                   --Mahatma Gandhi
USA               |