[omniORB] error messages

[David Riddoch]

On Tue, 12 Sep 2000, Stefan Seefeld wrote:

> I'm debugging a program which produces the following
> output:
> 
> omniORB: ERROR -- A servant has been deleted that is still activated.
>  repo id: 
>       id: root<1996881920>
> 
> and I'm wondering what to make out of it. First a little detail:
> why is the repo id printed at all ? As it appears, this output comes 
> from the destructor of omniServant. The _mostDerivedRepoId() should always
> print "", as 'this' is now stripped off of everything else. So this
> line seems useless.

True enough, I'll get rid of it.


> Second, under what conditions can the above error happen ? I'm using
> PortableServer::RefCountBase mixins everywhere, i.e. I never delete objects 
> by hand, the deletion is triggered by a deactivation. The only possibility 
> I can imagine is that (by accident) an object was activated twice and now one
> of the associated objects is deactivated, i.e. the servant still ought
> to serve another object.

Deactivating the object decrements the reference count, and if the ref
count goes to zero then the object is deleted.  If you are seeing this
error _after_ the object has been deactivated, then yes, it implies that
the object has been activated twice.


> In fact, the current situation in my debug session is that the respective POA
> is shut down due to a killed client (we use a session based approach).

>From what you are saying here I get the impression that you intended that 
the object not activated in the root POA, but some POA associated with
the session.  However, the error message at the top says the the object
_is_ activated in the root POA.  I suspect you have accidentally
implicitly activated the servant in the root POA by calling _this() on the
servant before it was activated in the POA associated with the session.

To avoid such errors, never (ever ever) use implicit activation, and
consider using poa->servant_to_reference() or poa->id_to_reference() to
get a reference. These guarentee that you will not get a reference for
some spurious implicit activation in the root POA by accident!


Cheers,
David