[omniORB] valgrind (Re: Resize strategy for POA not reclaiming memory when servants are deactivated for omniORB 4.1.7)

[Jeff Frontz]

On Wed, Feb 5, 2014 at 8:43 AM, Duncan Grisby <duncan at grisby.org> wrote:

>
> Looking at the resident size of the process doesn't tell you a huge
> amount. You don't know how the kernel and C library are interacting to
> share memory management responsibility. You should use valgrind:
>
>   valgrind --tool=memcheck --leak-check=full myServerCommand
>
> That will tell you if it's really leaking memory.


Unless you do some additional instrumentation in your software (see
http://stackoverflow.com/questions/5591837/get-leaks-between-two-points-using-valgrind),
it won't tell you about any "creeping bloat" (or "temporary leakage"?)
that is eventually cleaned up by any static destructors/atexit() routines
(assuming, I guess, that omniORB internally makes use of such things).  I
suggested to Jason that he could use "VIRT" in the top output to track
memory growth.



> Don't worry about
> warnings from valgrind about omniORB transmitting uninitialised memory
> -- that's just GIOP padding bytes that don't need to be initialised.
>
>
Speaking of which, is there any reason omniORB doesn't do a memset on those
from the get-go?  Is there a significant performance penalty? It's always a
bit jarring to look at valgrind output and see the uninitialized memory
warnings -- then follow the stack to see that it's just omniORB.


Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20140206/1da9d3ec/attachment.html>