[omniORB] Deadlock in poa.cc and a question on (non-)standard behaviour

[Duncan Grisby]

On Thursday 26 June, Vladimir Panov wrote:

> The servant activates itself in its constructor; implements server-side 
> reference counting: when the reference count drops to 1 (the reference 
> from the POA) it deactivates itself and then (as a result of the 
> deactivation) it deletes itself.

You are misusing the semantics of servant reference counting. The
reference count is used for server-side references to the servant,
including the references the POA holds. There is no guarantee in the
spec that the POA holds just one reference to a servant; it might
choose to hold more than one. Calling deactivate_object when the
reference count hits a certain value is inherently risky, and not the
intended usage.

I don't know what you are trying to achieve with your current scheme.
Are you trying to count clients?  If so, you should use a separate
count to servant reference count.

[...]
> 1. I call orb->shutdown(true).

This tells all POAs to destroy themselves.

> 2. The POA deactivates the servant internally.

This is part of the POA destruction.

> 3. The POA calls _remove_ref(), the servant calls 
> poa->deactivate_object() which throws OBJECT_NOT_EXIST_POANotInitialised.

Indeed, because by now the POA has been destroyed.

[...]
> Is this the standard behaviour? Shouldn't the POA dereference its 
> servants and then deactivate what's left?

It is standard behaviour.  I don't understand your second question.
The POA holds a reference to your servant, in the active object
map. When the object is deactivated, either as part of POA
destruction, or with an explicit deactivate_object call, the POA
removes its reference to the servant.

[...]
> No matter what are the answers to the questions above, this is what happens:
> (poa.cc, line 1136-1137, function omniOrbPOA::deactivate_object)
>    pd_lock.lock();
>    CHECK_NOT_DESTROYED();

This is indeed a bug, and a very silly one. I'm amazed that it hasn't
been spotted before. I'll check in the obvious fix in a little while.

Cheers,

Duncan.

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