[omniORB] Memory leak checkers compatible with omni

[Renzo Tomaselli]

Jan,
    we use Rational Purify for Windows since years on OmniORB and its
applications. It flags as potential leaks many singleton allocations (e.i.
typecodes), but they are always static objects allocated just once and never
released (this topic was discussed several times on the list).
Besides that, it helped a lot to detect leaks, UMR, and so on.
Regards,

Renzo Tomaselli

----- Original Message ----- 
From: "Jan Olderdissen" <jan at ixiacom.com>
To: <omniorb-list at omniorb-support.com>
Sent: Wednesday, November 03, 2004 11:06 PM
Subject: RE: [omniORB] Memory leak checkers compatible with omni


> On second thought, calling orb->destroy() and CORBA::release(orb) is
better.
>
> Jan
>
> -----Original Message-----
> From: omniorb-list-bounces at omniorb-support.com
> [mailto:omniorb-list-bounces at omniorb-support.com] On Behalf Of Jan
> Olderdissen
> Sent: Wednesday, November 03, 2004 11:52 AM
> To: omniorb-list at omniorb-support.com
> Cc: Fabrizio Oddone; John Wood
> Subject: [omniORB] 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
>
> _______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list
>