Problem:
- Product Name: VisiBroker for C
- Product Version: All
- Product Component: Core
- Platform/OS Version: All
Invoking an operation of a CORBA object on one thread in the middle of executing the ORB::shutdown() or exit() function call on a different thread will cause an intermittent core dump at VISGIOPProtocolConnector::reconnect() in the client-side ORB.
The clean up may take a while during which all POAs have already been transitioned from ACTIVE to INACTIVE (see section "Managing POAs with the POA manager" of the Developer"s Guide for details on the state transition).
The following is a sample stack trace that you may encounter:
fcb58968 void VISGIOPProtocolConnector::reconnect(unsigned long long) (1989c00, 0, afc8, fcfc1944, fcb58930, 1989ca4) 38 fcb3fc44 ProtocolEngine::ProtocolConnector*VISIIOPBidder::Bid::getConnector(unsigned long long) (1971c00, 0, afc8, 1034, 0, 0) 198 fcb41554 ProtocolEngine::ProtocolConnector*VISPortfolio::getConnector(unsigned long long) (f81fb450, 0, afc8, 1986cf0, fcb40a28, fd87bdc8) 188 fcb4637c ProtocolEngine::ProtocolConnector*VISProtocolManager::getConnector(CORBA_Object*,IOP::IORValue*,unsigned long long) (e0ec3f0, 4875ba4, 4876cf0, 0, afc8, fcf97628) 8c fcb4b744 void VISDelegate::_bind(CORBA_Object*,unsigned char,unsigned char) (4893c80, 4875ba4, 75d4, 0, afc8, 0) 514 fcb5062c void VISDelegate::_verify_connection(CORBA_Object*,unsigned char) (4893c80, 4875ba4, 0, 4, fcff7678, fffffb2d) 810 fcb51ffc unsigned char VISDelegate::is_local(CORBA_Object*) (4893c80, 4875ba4, 0, 1c00, 400, 6930c) 2c
from here downwards, the stack will be related to user-defined IDL operations
Resolution:
Unlike in the server-side ORB, all incoming requests and servicing are coordinated by the internal dispatcher, however, the client-side ORB has no knowledge on how the user application design their requests sending and receiving logic and whether it is multithreaded.
Thus, when the ORB is shutdown() or destroy() by the user application explicitly, it is user responsibility in handling the life cycle of the ORB. The ORB will be deleting and cleaning up resources when it is triggered by the shutdown()/destroy() API call. The ORB will not be awared of a user thread continues to run and invoking CORBA object operation during the shutdown or clean up process. This would be lead to segmentation or memory fault when the resources that are freed and being used.
To resolve this issue, the user application has to apply the memory management and defensive programming practice on the object"s state and its transition:
1. Implement a synchronization mechanisms (semaphore or mutex). The separate threads that call ORB::shutdown()/destroy() and CORBA objects operation in the user application space should be synchronized.
Or,
2. Check the state of the POA manager prior to calling any operation using the following sample code:
try
{
// the_POAManager() will also detect that ORB is shutting down (POA deactivating) and will throw OBJECT_NOT_EXIST.
if (rootPOA && rootPOA->the_POAManager())
{
PortableServer_POAManager::State poaState = rootPOA->the_POAManager()->get_state();
cout << "poaState: " << poaState << endl;
if (poaState == PortableServer_POAManager::ACTIVE)
{
someObject -> someOperation();
}
}
else
{
cout << "Error: rootPOA or the_POAManager() is NULL." << endl;
}
}
catch(const CORBA::Exception& e)
{
cout << "Error: Stale reference detected" << e << endl;
}
This would avoid the intermittent core dump happening at VISGIOPProtocolConnector::reconnect(). The core is intermittent without the synchronization because the threads are yielded depending on the kernel scheduler and the sequence may be different even both threads are on the same priority.
#VisiBroker
#Security