[omniORB] OMNIORB_ASSERT(num_active_oas == 0); with omniORB 4.1.2 and 4.1.4

[Duncan Grisby]

On Mon, 2011-01-10 at 12:40 +0100, Martin B. wrote:

> The error occurs during ORB shutdown which is initiated by the main 
> (GUI) thread which is the same thread that also called ORB_init.
> All CORBA connections are already terminated during shutdown (that is, 
> the only client I had connected was already disconnected several seconds 
> before ORB shutdown is called.
> 
> objectadapter.cc : 509 - OMNIORB_ASSERT(num_active_oas == 0);

The problem is that a POA is considered destroyed slightly before it is
really destroyed, meaning there is a race condition if you manually
destroy a POA then shutdown the ORB while the POA is still being
destroyed.

[...]
> Note that my shutdown sequence (in thread 380) goes like this:
> 1) deactivate_object(..) of my main object in the omniINS POA
> 2) PortableServer::POAManager_var pman = other_poa->the_POAManager();
>     pman->deactivate(true, /*wait=*/false);
>     other_poa->destroy(true, /*wait=*/false);
>     other_poa = PortableServer::POA::_nil();
>     the_orb->shutdown(true); <<< assert is triggered here

That's a really complex shutdown sequence. Why not just call
orb->shutdown(true) ?  The problem is that other_poa->destroy() is still
running in a separate thread at the time orb->shutdown() starts. The
situation is made even more complex because pman->deactivate() and
other_poa->destroy() are busy clashing with each other as they try to do
some of the same things.

The best way to avoid the problem is to remove the concurrent complexity
of your shutdown sequence.

It's infeasible to avoid the race that's causing the assertion failure
without making the concurrency control much more complex than it already
is, so the best way to avoid the assertion will be to make it loop with
a small sleep if num_active_oas != 0.

Cheers,

Duncan.

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