[omniORB] Memory leak checkers compatible with omni

[Harri Pasanen]

Hi,

As it happens, I've been hunting down memory leaks lately. 
On Windows I've had limited success (but still some) with free tool 
from

http://www.codeproject.com/tools/leakfinder.asp

I haven't had the time to test another one, which is more recent:

http://www.codeproject.com/cpp/MemLeakDetect.asp

But if you can do it on Linux, valgrind does much more, and does it 
better. http://valgrind.kde.org/  A nice fast machine with lots of 
memory is desirable though.

I'm interested in hearing your experiences with the various tools.

-Harri

On Wednesday 03 November 2004 20:51, Jan Olderdissen wrote:
> 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


This message, including any attachments, is intended only for the person(s) to whom it is addressed. If you received it in error, please let us know and delete the message from your system. This message may be confidential and may fall under the duty of non-disclosure. Any use by others than the intended addressee is prohibited. Trema shall not be liable for any damage related to the electronic transmission of this message, such as failure or delay of its delivery, interception or manipulation by third parties, or transmission of viruses or other malicious code.