Saturday, August 01, 2015

The death of Purify

Purify is a memory debugger program used by software developers to detect memory access errors in programs, especially those written in C or C++. It was originally written by Pure Software.

My first experience of purify was way back in the days Motif programming around 1992. I used it to track down memory corruption and leakage bugs in my code for a complex oil and gas graphics program. After I had fixed my bugs I found that purify complained about loads of bugs in Motif. Over the next few years Motif got cleaned up dramatically, thanks in no small part to purify. I have been a keen user ever since and as time went on it was ported from Solaris to other flavours of UNIX and to Windows. A GUI was added, better support for multi-threading, it just got better and better.

Why was purify so good? Because at the time there was little else you could use that would do the same job in a completely comprehensive way. The other tools typically required access to the entire source of your product as recompilation was necessary. Other approaches included interposing special versions of new/delete and malloc/free which required special linking as sometimes special compilation as well. I saw one attempt at using a virtual machine, from IBM, but IMO it was a failure. I broke it with a simple 3 line program almost immediately. So I was very skeptical in the early days that emulation would ever work. Boy, was I wrong when it comes to valgrind. But valgrind wasn't around then. Remember, we are talking about how to debug legacy C++ that was written before valgrind was invented or linux was popular.

Pure Software acquired by Atria but the product continued to be good at that point and spread mainly by word of mouth. There were fully functional but time-limited trial versions. I used to say it was the next tool you should get right after the C++ compiler. But then it was acquired by Rational where it stayed for many years. It languished under the ownership of Rational who didn't seem particularly keen to sell it. One had to jump through hoops when one had finally won the argument to purchase licenses. These were not cheap but purify was so vastly superior to the other tools that the case could be made. Then the Rational purchase obstacles kicked in. One had to be determined. Then IBM acquired the product. If it was hard to buy from Rational it was almost impossible with IBM. And they neutered the demo/trail version, effectively making it so that it only spread by word of mouth. One could no longer use the trail version to evaluate it.

Fast forward to January 2015. IBM sold Purify to UNICOM. This sale has been disastrous for all users of purify. UNICOM no longer sell it. Instead they sell a product called PurifyPlus, which is a bundle of other tools developed by Pure Software and extended by subsequent owners. These tools are Quantify and PureCoverage, for performance and code coverage analysis respectively. These are and have always been good powerful tools. For some users it made sense to bundle them because if all three were desired the overall license fee was cheaper. Now there is no choice and buying all three is most definitely not for everyone. But there's more. You used to be able to purchase as many licenses as you wanted, from a single license to site-wide. Now UNICOM have made it so that the minimum number of licenses is FOUR. This makes it very expensive. Also a years support fees is compulsory. I recently got a sales quote for a client of mine and the quote was for over TEN THOUSAND dollars. Needless to say at that sort of price it was game over.

After discussion with some of my colleagues I have come to conclusion that UNICOM want to kill the entire product suite off. Why else would they only sell it to large enterprise outfits to whom tens of thousands of dollars for software purchases are as nothing? Effectively purify is dead. This is a serious problem for the development and maintenance of legacy C++ programs.

It's not a problem for any new C++ software development. Just start developing it on LINUX where valgrind is available. But valgrind will never be available for Windows. The problem is trying to purify a large Windows C++ program that cannot be ported to Linux (and where there may not be any need or desire to do so).

So I no longer recommend purify. It is consigned to the dustbin of history. What a pity, it was a fantastic tool right to the end.


Robert Evans said...


AFAICT, Valgrind can detect only problems managing dynamic memory (which, to be sure, is the hardest and most common area of problems)

Could Purify detect problems with static buffer overflow? My dim recollection is that it could.

Andrew Marlow said...

I am not sure. I think it can sometimes. I seem to recall I had one of these errors once in a bit of FORTRAN code that was being called from C. Purify didn't spot the error in the FORTRAN. But I think I have seen it catch similar errors in C and C++.

sourceopen said...

Is it possible to download Purify now? If yes, what is the link to it? If Purify is not good, what other tool can I use?

sourceopen said...

Where can i download Purify? If Purify is not good what other tool can I use?

Andrew Marlow said...

AFAICT, downloading purify seems to be no longer possible. The current owner, UNICOM, makes it extremely difficult to purchase the licenses for purify. If you persist, as I did for one of my clients, then you can get a quote and the option for a trail version is then given. But you need to chase the purchase order to get anywhere and my client declined.

Andrew Marlow said...

I have received a number of posts to this thread asking for where purify can be downloaded. I reckon that unfortunately, it cannot be. For people that feel the need I presume they are in the same boat that I often find myself in, a legacy project that is at least 20 years old where memory usage, heap management etc, is highly suspect. It is suspected that the product has many memory leaks and reports of crashes due to suspected heap corruption are not uncommon. In that case I have some advice:

1) If the project is locked into Windows then introduce a platform neutral layer into the architecture and move as much code as possible into that layer.
2) Pick a unit test framework and start to use it (my favourite is googletest, aka gtest). Remember Michael Feathers definition of a legacy project - one that does not have unit tests. As many tests as possible must be in the platform neutral layer.
3) Use valgrind on the unit tests to detect heap corruption and leaks.
4) Use lcov to provide a nice webpage summary of code coverage of the unit tests. Use these results to extend the unit tests to give greater coverage.