| Summary: | Crash on client when remote server disappears | ||
|---|---|---|---|
| Product: | TAO | Reporter: | Nanbor Wang <reis> |
| Component: | ORB | Assignee: | DOC Center Support List (internal) <tao-support> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | werchak |
| Priority: | P3 | ||
| Version: | 1.1.17 | ||
| Hardware: | x86 | ||
| OS: | Windows 2000 | ||
Looks like your stack trace comes from the NameService and I guess you have missed another element in your scenario. BTW, we thought we had a few such errors fixed in previous betas. Can you please try running $TAO_ROOT/tests/*Crash* tests to see what is happening. On Win2K, you may see a failure of Crash_On_Write. That is because Win2K/NT seems to have a straange behaviour. HTH Actually, it is Server A that is crashing and the NameService is running on Server B. I believe it has more to do with the code that handles the shutdown of connections, perhaps a double shutdown of the same connection or something. I will try and dig up some more information on it. Jonathan Accepted on behalf of tao-support. |
I'm seen this stack trace a number of times. Could someone please tell me if it is a known bug or not? Operational Descriptions ++++++++++++++++++++++++ I have two servers, A and B, running the same service; service B is the master. When ervice A starts up it performs an initial 'Get' on service B. If the data changes on server B, it does a 'Put' to server A. So at one time or another A+B are both clients and servers. If I kill server B, sometimes, not always I get the following stack trace on server A. The line of code in the debugger is show by the --->> template <class ACE_SELECT_REACTOR_TOKEN> int ACE_Select_Reactor_T<ACE_SELECT_REACTOR_TOKEN>::remove_handler (ACE_Event_Handler *handler, ACE_Reactor_Mask mask) { ACE_TRACE ("ACE_Select_Reactor_T::remove_handler"); --->> ACE_MT (ACE_GUARD_RETURN (ACE_SELECT_REACTOR_TOKEN, ace_mon, this- >token_, -1)); return this->remove_handler_i (handler->get_handle (), mask); } ACE_Select_Reactor_T<ACE_Select_Reactor_Token_T<ACE_Token> >::remove_handler (ACE_Event_Handler * 0x030678b0, unsigned long 1023) line 368 + 12 bytes ACE_Reactor::remove_handler(ACE_Event_Handler * 0x030678b0, unsigned long 1023) line 316 TAO_Transport::close_connection_i() line 697 TAO_Transport::close_connection() line 656 TAO_GIOP_Invocation::close_connection() line 536 TAO_ORB_Core::service_raise_comm_failure(TAO_GIOP_Invocation * 0x01baf720, TAO_Profile * 0x00f810e8, CORBA_Environment & {...}) line 1501 TAO_GIOP_Synch_Invocation::invoke_i(unsigned char 0, CORBA_Environment & {...}) line 768 + 41 bytes TAO_GIOP_Twoway_Invocation::invoke(TAO_Exception_Data * 0x002a4060 _tao_CosNaming_NamingContext_resolve_exceptiondata, unsigned int 3, CORBA_Environment & {...}) line 910 + 17 bytes CosNaming::_TAO_NamingContext_Remote_Proxy_Impl::resolve(CORBA_Object * 0x00f9d2b8, const CosNaming::Name & {...}, CORBA_Environment & {...}) line 2998 + 23 bytes CosNaming::NamingContext::resolve(const CosNaming::Name & {...}, CORBA_Environment & {...}) line 5206 NAMING_CLIENT::NamingClient::resolveOrCreateContext(CosNaming::NamingContext * 0x00f9d2a8, const char * 0x03061208) line 337 + 39 bytes NAMING_CLIENT::NamingClient::set(const ACE_CString & {...}, CORBA_Object * 0x010241e8)