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.
{
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
