[omniORB] RE: Memory leak checkers compatible with omni

[Caine, Ian]

My personal experiences with Purify have largely been rather bad: it's very slow, you can't control what is instrumented and what isn't and (on HP-UX) I had endless problems with analysing any programs that linked with OpenGL - and rather poor support from Rational trying to get this problem resolved.

I much preferred Insure (from Parasoft) mostly because none of the above problems occur: you can control what libraries are instrumented, meaning that if you trust OmniOrb (for example), you don't have to analyse it. This also means it both instruments and runs much faster. The major drawback is that it costs very much more than Purify.

-----Original Message-----
From: omniorb-list-bounces at omniorb-support.com [mailto:omniorb-list-bounces at omniorb-support.com] On Behalf Of Jan Olderdissen
Sent: 15 November 2004 19:18
To: omniorb-list at omniorb-support.com
Cc: Fabrizio Oddone; John Wood
Subject: [omniORB] RE: Memory leak checkers compatible with omni


As a follow-up to my own post:

1. A number of list members suggested Purify. Purify works well with omniorb and certainly looks to be the most thorough and mature product of the bunch. It has one major drawback: It is the slowest of the products I tested - by far. A colleague ran Purify with his application. He gave up after the GUI for his app didn't come up after 48 hours of 100% CPU utilization. :-)

2. The Memory Validator folks (softwareverify.com) were very courteous and helpful. Their tech support quickly jumped on the two bugs I reported. As of today, these issues have been resolved and I can recommend Memory Validator as a good balance between performance and strictness for use with omniorb.
 
Jan

-----Original Message-----
From: Jan Olderdissen 
Sent: Wednesday, November 03, 2004 11:52 AM
To: 'omniorb-list at omniorb-support.com'
Cc: John Wood; Fabrizio Oddone
Subject: Memory leak checkers compatible with omni

Hi,

I've been running two commercial memory leak checking tools against an application that makes heavy use of omniORB 4.0.3 on Win2k/XP. Sadly, I haven't had good luck with either of them. Results below. 

Has anyone had better experience with other products?

Jan


--------------
Test results:

1. Memory Validator 3.75 (softwareverify.com)

This product seems to get very confused by methods called free(). For example, uses of _CORBA_String_helper::free(_ptr) get flagged as a new/free mismatch even though _CORBA_String_helper::free() properly uses delete[] internally.

Probably for similar reasons I get a truckload of incorrectly flagged memory leaks when copying objects from classes generated with the IDL keyword 'exception'. All data members of the exception get flagged as leaked even through single-stepping clearly shows new/delete being called for each of the data areas the members point to. Also, causing a few thousand exceptions artificially does not grow the memory footprint of the process so I'm inclined to conclude these to be false positives.

Using filters to deal with the false positives was futile. Each additional unit test of our app I ran yielded dozens to hundreds more false positives despite filtering. Also, having to add too much filtering makes you wonder whether you're covering up actual leaks.

Incidentally, memory validator crashed once and hung once when working with filters.

I did discover that omniORB appears to require both 'orb->destroy()' and 'delete orb' to eliminate all allocated blocks. Using only 'delete orb' causes massive leaks while only using 'orb->destroy()' leaks the orb object itself but no sub-objects. This smells like a slight bit of non-conformance as H+V only show the use of 'orb->destroy()'.

2. Glowcode 5.1 (glowcode.com)

Glowcode does not appear to have Memory Validator's feature of actually tracking new/delete alloc/free pairs. Instead it appears to heuristically determine memory leaks by searching memory for pointers to possibly leaked blocks. If no pointers are found, the block is flagged. Unfortunately, that leaves me with over 1700 blocks remaining at the exit of the app even if the app didn't to anything, which pretty much defeats the purpose of this exercise. Note that Memory Validator does not flag any leaks in this basic test other than the intentional leak I threw in for validating the tools.

Summary:

Memory Validator's mechanism of tracking new/delete, alloc/free (and so on) pairs yields much cleaner results than Glowcode's heuristics. MVs inability to deal with class methods called free() makes it unusable for applications using OmniORB.

_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com http://www.omniorb-support.com/mailman/listinfo/omniorb-list