Exceptionally good news for the commercial Linux developers. Rational has released PurifyPlus for Linux. For hobby developers, the free Valgrind is better than nothing, but for commercial projects and for projects that require a full featured memory management tool, PurifyPlus has no match. Demo available.
Rational Releases PurifyPlus for Linux
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I’m interested that you think valgrind is merely ‘better than nothing’, what do you like in purify that isn’t part of valgrind? I’ve used both and found them pretty much equivalent. With the recent addition of cachegrind for profiling (and the new GUI kcachegrind see http://dot.kde.org/1031085340/ ) it would seem to me that valgrind has the upper hand.
Rich.
I haven’t used Purify, but my husband has. He uses it every day at work. A few weeks ago I asked him to go through Valgrid and tell me what he thinks (I wanted to make a longer story about it, if it was indeed what the Linux people are making it to be). JBQ’s result was that Valigrid does not do nearly as much as Purify can do, and it does not catch the most important cases, but only the simple ones. He said that Valgrid is barely useful *compared* to Purify. Compared to having nothing though, Valigrid can be useful.
I have nothing against Valgrid. I think it is great that it is here. But the fact that it is Free and open source does NOT make it a better tool that should get praise over here. I will not praise it just because it is GPL and because it might be unique in the linux world and everyone eats the hype around it. Especially when there is a PurifyPlus that does so much more (for a hefty price of course – that is not my concern when compare their features).
Well, I haven’t used valgrind at all, I just read some specs a while ago.
In a nutshell, Purify’s UMCs and API parameter checking are two must-haves (besides the “trivial” features, of course).
Quantify is the best profiler I have ever used (detailed reporting, ease of use, super-easy filtering), and PureCov “just works”.
JBQ
I have to disagree with your husband I’m afraid, but as the versions of purify I’ve used are quite old, maybe it has improved. Certainly the early versions of valgrind weren’t as good, but recent versions are pretty damn good and I’ve found it better in some ways (eg. purify used to cause crashes in some motif code i applied it too).
Regarding your second paragraph, I’m not trying to make a GPL vs. commercial comparison just a technical one.
Rich.
ps. It’s valgrind not valgrid!
> …for a hefty price of course…
The Shop –> Buy Products page an Rational doesn’t list a “Linux” version of PurifyPlus, but the UNIX version is priced at $4794 (USD) for a single-user (“Named-User”?) license. Za!
That price is for Solaris/HP-UX and IRIX.
The price for Windows is ‘only’ $1200. I think the Linux version should be around $1200 as well.
I’ve dug around rational’s site a little and found a download site for a one week demo: http://www.rational.com/tryit/purifyplus_linux/index.jsp when I have some time I might well try to do a proper comparision of the two.
Rich.
Rich, if you want, we would be happy to host an article here on osnews with your comparison.
If I get a chance to do the comparison, i’ll drop you a mail. The main pain would be in devising a suitable set of bugs to look for, so I can see which spots the most (and reports the results most usefully).
Rich.
Or, just use it without try to devise plans… It would be BEST to not try to create bugs on purpose, but to do your job normally and then check out which one spots the most. It would be more fair this way.
The trouble with doing it that way is that complex programs may well execute different code paths depending on run-time differences (eg. timing) as a result the comparison might be flawed. I suspect a mixture of the two is needed for a fair test.
Rich.
I really do like valgrind (although its being tied to Linux is somewhat annoying), but PurifyPlus just blows it away. valgrind doesn’t work on multithreaded applications, whereas PurifyPlus was able to identify a number of race conditions in some of my multithreaded code. I suppose “You get what you pay for” really holds true in this case. Unfortunately I don’t think I’ll be able to afford PurifyPlus for my own personal use…
>valgrind doesn’t work on multithreaded applications
Thats totally incorrect. I have used it in multithreaded applications without a problem. _Note_ that you need to dynamically link against libpthread if you use pthreads.
Valgrind is a must if you can’t afford/want to buy another memory debugger.
JBQ>
What does UMCs mean? Uninitialized Memory C..?
>JBQ’s result was that Valigrid does not do nearly as much
>as Purify can do, and it does not catch the most important
>cases, but only the simple ones.
What are the most important cases if I may ask?
I don’t know if anyone agree with me but catching
“Read/Write use of uninitialised memory” is in my book the most important future. Anyone disagree?
>What does UMCs mean?
Uninitialized Memory Copies.
This sort of statement is why I won’t be running any Linux distribution in the near future. Too many Linux out there.
I think Dan Bernstein is perfectly capable of making code which does not have memory leaks without needed to lean on a crutch like Valgrind or Purify. The problem with these tools is that they encourage developers to use data structures which are too complicated to debug easily; these tools fix the symptoms and not the underlying problem.
That said, my users have run Valgrind on my code (http://www.maradns.org) to find some subtle leaks (I have other tools for finding big memory leaks) and cases of uninitialized data currupting the heap (This is what happens when I change data structures in mid-stream without having a good plan).
Ideally, I would like to write bug-free code which does not need any high tech crutches like this.
– Sam
I am sorry, I do not want to sound rude, but this post of yours is just not serious. There is not such thing as “perfect bug-free code”, especially when the app in question is kinda complex.
>Ideally, I would like to write bug-free code which does not need any high tech crutches like this.
Wow. You must have an IQ of 300. I applaud you. But please remember that most programmers are possibly not as gifted as you might be. Also, even yourself, you use these “other tools” to detect memory leaks.
There is a product called Insure++ from ParaSoft. Anyone used it on Linux?
Sam, how long have you been programming? Have you worked on any project of medium/large size ( > 250,000 lines )?
Bug exist and will exist. Not that this should be an acceptable thing, but it’s a fact none the less.
Source code/object-code instrumentation tools are rather critical to ends of producing bug free code (at least code that has less bugs).
Seriously, those tools are precious. Usually, people don’t go through the pain of writing bug-free code “the first time”, because it’s an extremely complex task as soon as you have more than one programmer. It’s cheaper to write it “almost bug-free”, find bugs through testing, diagnose them and fix them.
Writing bug-free code works in Theory. Problem is, Theory is a mythical land that nobody has found yet. Those of us working down there in Silicon Valley (or elsewhere) live in a world where bugs are a day-to-day reality, where compiler warnings, lint, effective C++ rules and purify are precious allies.
What’s great about tools like PurifyPlus is that they’ll allow you to find bugs before they even have any visible effect. Catching a FMW (Free Memory Write) is a piece of cake with such a tool – it can take days of testing and hours of debugging otherwise.
Following UMCs (uninitialized memory copies) is very important, because they allow to catch UMRs (uninitialized memory reads) very precisely. There are many harmless UMCs in a normal program, and a Purify-like tool that doesn’t follow them is far less useful in my opinion.
Examples where the proper handling of UMCs is important:
struct s {int i;char c;};
void f() {
struct s a,b,c,d;
a.i=0;
memcpy(&b,&a,sizeof b);
memcpy(&c,&a,sizeof c);
c.c=0;
a.c=0;
memcpy(&d,&a,sizeof d);
printf(“%c %c %c
“,b.c,c.c,d.c);
}
JBQ, who don’t know if French citizens are allowed to work in Theory.
> Writing bug-free code works in Theory.
I would like to see that Theory. Sources?
About the same argument can be heard sometimes from the people who write in pure assembly these days (not that many of them anymore though), the compiler is a high-tech crutch as much as a good memory debugger is really.
Sam, how long have you been programming?
Off and on, over 22 years.
the compiler is a high-tech crutch as much as a good memory debugger is really.
The compiler is there so that my code can run on multiple platforms without needing to rewrite the code. I wrote my code for Linux, but have users who run my code on Windows, for example.
The kind of code I write these days is network daemons. This kind of code where bugs are not acceptable. The smallest memory leak can not be tolerated; even a single reference to allocated memory is dangerous. The bugs which I find are not the ones which worry me. The bugs which I do <em>not</em> find are the ones which an attacker can use to break in to systems which run my software.
If I code in such a way that coding mistakes are common enough that I need to constantly use a profiler to find them, I will inevibably have security holes in my code. NASA is perfectly of writing code which is bug-free without needing a profiler. As is Dan Bernstien. Naturally, these kinds of coding techniques emphasize stability over features; I understand that most corporate people want code which has a lot of shiny toys (features). Stability is not nearly as important to these people.
I have seen visual basic code written by people who had no sense of good coding practice, who used all of the crutches in Microsoft’s IDE environment to organize their code. I am talking about 6000 lines of spagetti code without a single comment. This is the kind of code which is made when people depend too much on crutches.
Again, my code is out there in the open. http://www.maradns.org for anyone who is interested.
– Sam
JBQ, what do you expect your memory debugger to tell you about that program? Is it just that you don’t want an error reported until the unintialised memory is really used (in the libc’s printf implementation) ? Or do you want diagnostics to tell you where that uninitialised memory came from (which is a tricky question) ?
I only have an ancient version of Valgrind, so it will inevitably have improved since I last used it (I have a PhD thesis to write, so no coding for me at the moment). The following observations are based on a version from February.
Valgrind tells me that the printf() call resulted in a system call that accessed uninitialised memory. I can narrow the problem down to b.c, but it doesn’t include a trace that shows why b.c isn’t initialised, so I have to figure that out for myself.
What would Purify say?