Jeff Frontz
2014-02-06 16:09:19 UTC
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
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 (seeamount. You don't know how the kernel and C library are interacting to
valgrind --tool=memcheck --leak-check=full myServerCommand
That will tell you if it's really leaking memory.
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 thosewarnings from valgrind about omniORB transmitting uninitialised memory
-- that's just GIOP padding bytes that don't need to be initialised.
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>