Please report new issues athttps://github.com/DOCGroup
Created attachment 1326 [details] The log file. The given patch in bug 3913 fixes that issue. But at the end of the applications it causes an unexpected termination in the locality manager during the teardown phase. Attached is the log.
Does this occur without your interceptor installed?
This doesn't occur when interceptor is not installed. Actually this occurs when ::CORBA::ORB_init() is there in the interceptor. According to the following log portion problem occurs when StockDistributor stop publishing Quotes. The application as a whole is now started. Lets subscribe and unsubscribe some stock Start the Stock Distributor by invoking 'StockDistributorDriver -o -r 1' Start up the Distribution service Now subscribe to MSFT by invoking 'StockBrokerDriver -s MSFT' StockBroker_exec_i::stock_subscribe - subscribe to <MSFT> Subscribe successful! Now subscribe to IBM by invoking 'StockBrokerDriver -s IBM' StockBroker_exec_i::stock_subscribe - subscribe to <IBM> Subscribe successful! Now subscribe to invalid stock by invoking 'StockBrokerDriver -s CIAO' StockBroker_exec_i::stock_subscribe - <CIAO> not found. Throw Invalid_Stock exception. Invalid stock exception. Now UNsubscribe to IBM by invoking 'StockBrokerDriver -u IBM' StockBroker_exec_i::stock_unsubscribe - unsubscribe <IBM> Unsubscribe successful! Stop the Distributor by invoking 'StockDistributorDriver -f' Stop the Distribution service ERROR: C:\research\cuts-thirdparty\doc-middleware\Latest_Micro\ACE_wrappers\TAO\CIAO/tutorials/Quoter/Simple/lib/StockDistributorDriver timedout We're done. Stop the application now by invoking the plan_launcher again This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Invoking executor - stop the application -
Why should an interceptor do an init, wouldn't expect that in an interceptor
From an out-of-band email from James: In short, we are trying to plugin into the ACE logging facilities and intercept log messages so we can store them in a offline server. To do this, we have a server that run on another machine and we use CORBA as the communication medium for sending messages to the logging server. When the ACE-based service is loaded by the service configurator, it initializes an ORB based on the services parameters provided in svc.conf. Some of the parameters include the location of the logging service, number of threads to use in the ORB, delay time for sending messages to server, and number of messages to include when communicating with the logging server. In the past, we have used a separate ORB to handle the needs of the ACE logging interceptor so as not to disturb the main ORB that application is using.
It wouldn't surprise me if the interceptor installed by the user is being destroyed too late in the game. In prior versions of DAnCE, there were lots of memory leaks and things weren't cleaned up properly. Now that we're cleaning up better, it may be that the ORB pointer being held by the interceptor is invalid when the service object is cleaned up by ACE. Would it be possible for you to get a stack trace Manjula?
The stack trace does not contain high level calls. But it is a problem with the memory cleanup. > msvcr90d.dll!_NMSG_WRITE(int rterrnum=10) Line 198 C msvcr90d.dll!abort() Line 59 + 0x7 bytes C msvcr90d.dll!terminate() Line 130 C++ dance_locality_manager.exe!__CxxUnhandledExceptionFilter(_EXCEPTION_POINTERS * pPtrs=0x01cff0e8) Line 70 C++ kernel32.dll!764c2c2a() [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll] msvcr90d.dll!_getptd_noexit() Line 618 C msvcr90d.dll!66975bf7() 00000001() KernelBase.dll!75c39617() KernelBase.dll!75c39617() KernelBase.dll!75c39617() ACEd.dll!ACE_OS::memcpy(void * t=0x00000000, const void * s=0x668dbb8c, unsigned int len=0) Line 42 + 0x11 bytes C++ TAOd.dll!CORBA::MARSHAL::~MARSHAL() Unknown
That would tend to validate my theory. I'm inclined to believe that this isn't a bug in DAnCE, but is a problem in the interceptor code. Could you provide a log of just a single node, with ORB Debug and DAnCE debug set at 10?
Created attachment 1327 [details] The log file after setting debug levels to 10 The log file for node distributor is attached. This is after setting the log levels to 10.
Please also set DANCE_LOG_LEVEL=10, in addition to the ORB debugging.
That log was generated after creating DANCE_DEBUG_LEVEL to 10.
Ahh. I see. That log seems to indicate that the locality manager process crashes during 'application' run-time, and not when things are tearing down.
Yeah. I corrected this in my second comment. Seems to me the problem occurs when any of the application's ORB destroying. Actually I ran the application after commenting out the destroy_orb() statements of applications but problem was still there. I also commented out destroy_orb() in localitiy_manager but no success.
can you check all code whether there is a try/catch around each corba call, seems a corba exception is thrown but never caught