[omniORB] Memory leak with omniORB when calling ORB::run() from non-omni-thread

[Duncan Grisby]

On Mon, 2010-12-20 at 11:38 +0100, Martin B. wrote:

> We call ORB::run() from a thread that was not created as an omni_thread 
> (created by _beginthreadex on Windows).

Sorry for taking ages to reply to this. It got buried under other
things...

> I have now noticed a memory leak due to this, specifically the 
> _internal_omni_thread_dummy object created by the call to 
> omni_condition::wait() in omniOrbORB::run() (line 819/820) is never 
> free'd as far as I can see.

[...]
> 1) Is this leak intentional or an oversight?

It's intentional. On Windows the condition variable implementation has
to store information on the omni_thread object, so if you call a
condition wait() method from a non-omni_thread, it has to create a dummy
omni_thead object for it.

The dummy object is cached to avoid the overhead of creating them.
There's no safe time to delete the cached object, so it's allowed to
leak. There will only ever be as many of these dummy objects as there
are concurrent calls to condition wait from different non-omni threads.

> 2) Is there actually a leak or am I doing something wrong? (apart from 
> the fact that I call run() from a non-omni-thread thread, which I am not 
> sure is "suppoerted")
> 3) I can think of the following fixes, please comment:
>    3.1) Call run from an omni_thread

The best answer is to simply not call orb->run() at all. There's no need
to do so in omniORB. All run() does is block waiting for shutdown.
(Unless you're using a main thread policy POA, and you're calling run()
from the main thread.)

Duncan.

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