Bug 978 - Crash on client when remote server disappears
Summary: Crash on client when remote server disappears
Status: RESOLVED DUPLICATE of bug 1202
Alias: None
Product: TAO
Classification: Unclassified
Component: ORB (show other bugs)
Version: 1.1.17
Hardware: x86 Windows 2000
: P3 normal
Assignee: DOC Center Support List (internal)
URL:
Depends on:
Blocks:
 
Reported: 2001-07-19 10:12 CDT by Nanbor Wang
Modified: 2002-08-10 21:54 CDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nanbor Wang 2001-07-19 10:12:44 CDT
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)
Comment 1 Nanbor Wang 2001-07-19 10:29:56 CDT
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
Comment 2 Nanbor Wang 2001-07-19 10:42:26 CDT
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
Comment 3 Ossama Othman 2001-08-03 12:08:38 CDT
Accepted on behalf of tao-support.
Comment 4 Carlos O'Ryan 2002-08-10 21:54:38 CDT
Gosh, this one is a duplicate, shame on us... it was reported way back!

*** This bug has been marked as a duplicate of 1202 ***