Hi there,
Over the last year of using MICO 2.3.11, we've had (at least) four
crashes in the line "servant->_remove_ref()" in the POAObjectReference
destructor:
MICOPOA::POAObjectReference::~POAObjectReference ()
{
CORBA::release (obj);
CORBA::release (poa);
obj = NULL;
if (servant) {
servant->_remove_ref();
}
}
The POAObjectReference destructor is being invoked from
poa_imple::remove_object(), at the end of the following (edited) snippet:
if (!CORBA::is_nil (servant_manager)) {
PortableServer::ServantActivator_var sav =
PortableServer::ServantActivator::_narrow (servant_manager);
PortableServer::Servant serv = orec->serv;
POAObjectReference * por = orec->por;
orec->por = NULL;
delete orec;
if (thread_policy->value() == PortableServer::SINGLE_THREAD_MODEL
|| thread_policy->value() == PortableServer::MAIN_THREAD_MODEL) {
MICOMT::AutoLock t_lock(S_servant_manager_lock);
sav->etherealize (por->get_id(), this, serv, FALSE, other);
}
else {
sav->etherealize (por->get_id(), this, serv, FALSE, other);
}
delete por;
}
In our setup, we have installed a ServantManager whose etherealize
method deletes the servant. We understand that this is allowed, not
only from samples that come with MICO and on the Web that show that, but
also from the CORBA spec:
"11.3.6:
"In a multi-threaded environment, the POA makes certain guarantees that
allow servant managers to safely destroy servants. ... Therefore, when
etherealize is called, the servant manager can safely destroy the
servant if it wants to, unless the remaining_activations argument is TRUE."
As well, in "Advanced CORBA Programming with C++", it says on page 500:
"...the POA invokes the etherealize method of the ServantActivator for
the deactivated object's servant. This allows the application to take
action to clean up the servant, such as invoking _remove_ref on the
servant or calling delete on it. The POA guarantees that it will not
access the servant in any way after it passes it to etherealize."
But that's not what we're seeing here. We're seeing the call to
etherealize, followed by the call to POAObjectReference's destructor,
which *does* access the servant.
Because the servant is destroyed by the time we get to
POAObjectReference's destructor, we occasionally get a crash in the rare
case that the object's memory has been overwritten between the delete
and the access.
So, is there a MICO issue here? Or are we using and/or interpreting the
library incorrectly? (Note that MICO 2.3.12 appears to work the same
way as 2.3.11, so I don't think that upgrading will fix the problem for us.)
-- Keith Rollin
-- CyberArts, Inc.
_______________________________________________
Mico-devel mailing list
[email protected]
http://www.mico.org/mailman/listinfo/mico-devel
