[omniORB] Memory leak related to Proxy Object Factories

[Duncan Grisby]

On Thursday 14 December, Tuyen Chau wrote:

> I've looked into the omniOrb code as you suggested and it is not as
> straight forward as it sounds, so instead, I looked for work arounds.
> The work-around that we came up and are happy with, is to create a
> dummy objref to take ownership of the ior and identity, and set a
> timer for 1 second with the dummy objref passed into the timer handler
> as a parameter.  When the timer expires, the timer handler gets
> called, and releases the dummy objref.
> 
> In this work around, we assume 1 second is long enough to execute the
> omniOrb code between the newObjRef() call and before calling our code.
> We also assume that returning a cache objref, instead of a new one,
> does not confuse omniOrb in any other way other than the memory leak
> problem.
> 
> We've tested our work-around and got mixed results.  In a simple test,
> the leak is gone.  In a much more complicated test that is supposed to
> run for days, we got a C++ Runtime exception (no pure virtual function
> call) that seemed to happen on a random basis.  We are not sure if the
> exception that we got is a different problem altogether or related to
> the work-around that we took.  Does this work-around look OK to you,
> or are we missing the boat here?

Most likely, you were unlucky and the 1 second timeout expired before
omniORB tried to call a method on the object. That would explain the
pure virtual method called error you see. I don't think your approach is
at all safe.

Why are you returning cached object references?  I was assuming that it
was to avoid the overhead of constructing new ones, but if you consider
it acceptable to create a new one then immediately delete it again, that
can't be the reason. So you must be doing it to share some state between
them. Rather than trying to fight omniORB's desire to create new
objrefs, why don't you put whatever shared state you have into a
sub-object that is shared between all the objrefs that omniORB creates.
That way you can do whatever it is you need without having to subvert
what omniORB tries to do.

Cheers,

Duncan.

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