[omniORB] Resize strategy for POA not reclaiming memory when servants are deactivated for omniORB 4.1.7

[Duncan Grisby]

On Tue, 2014-02-04 at 13:26 -0500, Jason Hein wrote:
> We put a log message in the destructor of the servant class to ensure
> that the object clean-up was happening correctly. We even put
> additional _remove_refs in the code to force a segfault condition to
> verify that reference counting was triggering correctly. We ran a test
> to place 100000 NamedCounterImpl servants into a child POA using the
> AddNamedCounter method. We then followed up with calling the
> RemoveNamedCounter method with the same name sequence. 
> 
> ..... Output from server process, 100000 calls to AddNamedCounter
> 
> Counter goober_99995 added with a value of 0
> Counter goober_99996 added with a value of 0
> Counter goober_99997 added with a value of 0
> Counter goober_99998 added with a value of 0
> Counter goober_99999 added with a value of 0
> omniORB: Deinitialising omniDynamic library.

I find that concerning. Why is omniORB deinitialising the omniDynamic
library at that stage?  It should only do that when the system is
shutting down. Are you dynamically loading and unloading libraries?

[...]
> For our tests we used the top command and isolated the server process
> and then recorded the RES value for each step of test.  We are running
> on CentOS 6.3 x86_64, with omniORB 4.1.7.

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. 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.

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --