[omniORB] RE: Memory leak checkers compatible with omni

[Jan Olderdissen]

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.