| Summary: | TAO_ORB_Core destructor seg faults | ||
|---|---|---|---|
| Product: | TAO | Reporter: | levine |
| Component: | ORB | Assignee: | Irfan Pyarali <irfan> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | coryan, ossama.othman |
| Priority: | P1 | ||
| Version: | 0.4.2 | ||
| Hardware: | All | ||
| OS: | All | ||
|
Description
levine
1999-07-23 12:54:26 CDT
Purify on NT did not show any problems ;) I'll try to debug this further next week (before leaving on vacation). Reassigned to Irfan to track since it is a test related to the POA. David says that this problem happens in all TAO tests. RootPOA seemed to be
the simplest one that demonstrates it. Though the stack trace is now different:
#0 0x1003d4a0 in CORBA_Any::replace ()
#1 0x10026e9c in TAO_ORB_Core::~TAO_ORB_Core ()
#2 0x1002a7d0 in TAO_ORB_Core::fini ()
#3 0x10002a64 in CORBA_ORB::~CORBA_ORB ()
#4 0x10001cc8 in main (argc=1, argv=0x7ffffff8)
at /project/danzontmp/levine/ACE_wrappers/build/lynx-ppc/ace/OS.i:2306
#5 0x10274d7c in runmainthread ()
#6 0x10001048 in __start ()
Dan Butler of Boeing has asked for a priority increase on this. I don't know if it's the same problem, but here's where it dies on VxWorks: f42ee19 RootPOA_text +39 : __$_18ACE_Object_Manager (ff163cc, 2) f780dfa __$_18ACE_Object_Manager+1a : ACE_Object_Manager::_fini(void) (ff163cc) f78141a ACE_Object_Manager::_fini(void)+3a : ACE_OS_Exit_Info::_call_hooks(void) (ff163dc) f77d3c6 ACE_OS_Exit_Info::_call_hooks(void)+2a : _ace_cleanup_destroyer (fee5918, 0) f77ec03 _ace_cleanup_destroyer+17 : f4a711c ([fee5918, 0, ff1638c, f77d3cb, fee5918]) f4a7121 ACE_Singleton<TAO_ORB_Table, ACE_Thread_Mutex>::_cleanup(void *)+19 : __$_t13ACE_Singleton2Z13TAO_ORB_TableZ16ACE_Thread_Mutex (fee5918, 3) f4baf09 __$_t13ACE_Singleton2Z13TAO_ORB_TableZ16ACE_Thread_Mutex+11 : __$_13TAO_ORB_Table (fee591c, 2) f4a658d __$_13TAO_ORB_Table+45 : TAO_ORB_Core::_fini(void) (fedd3f0) f4a47e9 TAO_ORB_Core::_fini(void)+241: __$_12TAO_ORB_Core ([fedd3f0, 3, ff16330, ff16338, fee591c]) f4a1c46 __$_12TAO_ORB_Core+10e: __$_18TAO_ORB_Parameters (fedd410, 2) f564a28 __$_18TAO_ORB_Parameters+18 : __$_19TAO_IOR_LookupTable (fee9078, 3) f559f1e __$_19TAO_IOR_LookupTable+e : __$_t23ACE_Hash_Map_Manager_Ex5Z11ACE_CStringZ11ACE_CStringZt8ACE_Hash1Z11ACE_CStringZt12ACE_Equal_To1Z11ACE_CStringZ14ACE_Null_Mutex (fee9078, 2) f55a6cc __$_t23ACE_Hash_Map_Manager_Ex5Z11ACE_CStringZ11ACE_CStringZt8ACE_Hash1Z11ACE_CStringZt12ACE_Equal_To1Z11ACE_CStringZ14ACE_Null_Mutex+c : f55a6a0 (fee9078) f55a6aa ACE_Hash_Map_Manager<ACE_CString, ACE_CString, ACE_Null_Mutex>::_hash(ACE_CString const &)+1ca: ACE_Hash_Map_Manager_Ex<ACE_CString, ACE_CString, ACE_Hash<ACE_CString>, ACE_Equal_To<ACE_CString>, ACE_Null_Mutex>::_close_i(void) ([fee9078, 0, ff162ac, f55a6d1, fee9078]) f55afa2 ACE_Hash_Map_Manager_Ex<ACE_CString, ACE_CString, ACE_Hash<ACE_CString>, ACE_Equal_To<ACE_CString>, ACE_Null_Mutex>::_close_i(void)+62 : __$_t18ACE_Hash_Map_Entry2Z11ACE_CStringZ11ACE_CString (296, 2) f55bcc1 __$_t18ACE_Hash_Map_Entry2Z11ACE_CStringZ11ACE_CString+11 : __$_11ACE_CString (2aa, 2) f797b36 __$_11ACE_CString+12 : ACE_CString::_set(char const *, unsigned int, int) (2aa, 0, 0, 0) ORB_Core initialization and destruction has recently gone through a series of updates (they'll be in TAO 1.0.5). Does the problem still show up with today's changes? Yes, the problem is still there on LynxOS/PPC. There isn't much of a stack trace: Program terminated with signal 4, Illegal instruction. #0 0x20004d0c in TAO_POA_Current virtual table () Here's the current stack trace on LynxOS/PPC, with ACE_HAS_NONSTATIC_OBJECT_MANAGER: #0 0x1003e274 in CORBA_Any::replace () #1 0x10027dbc in TAO_ORB_Core::~TAO_ORB_Core () #2 0x1002b630 in TAO_ORB_Core::fini () #3 0x1002e314 in TAO_ORB_Table::~TAO_ORB_Table () #4 0x10032b9c in ACE_Singleton<TAO_ORB_Table, ACE_Thread_Mutex>::~ACE_Singleton () #5 0x10031510 in ACE_Singleton<TAO_ORB_Table, ACE_Thread_Mutex>::cleanup () #6 0x101cc748 in ace_cleanup_destroyer () #7 0x101c9d88 in ACE_OS_Exit_Info::call_hooks () #8 0x101d00b4 in ACE_Object_Manager::fini () #9 0x101cf684 in ACE_Object_Manager::~ACE_Object_Manager () #10 0x100010cc in main (argc=0, argv=0x7ffffff8) at RootPOA.cpp:26 #11 0x1027da08 in runmainthread () #12 0x10001048 in __start () gdb can be run on the target. It doesn't show source code, but other than that is usable. The cause has been isolated to the destruction of poa_current_ in ~TAO_ORB_Core: ChangeLogTag: Sun Oct 10 09:17:26 1999 David L. Levine <levine@cs.wustl.edu> Just adding my address to the CC list since I have an interest in TAO_ORB_Core destruction. The poa_current_ field uses TSS storage, is it possible that the TSS destructors have been invoked before the ORB_Core destructor does? $ ./RootPOA
TSS destructors are invoked after poa_current_ would be
deleted, according to some printouts:
The RootPOA is :
ORB_Core.cpp:179 delete poa_current_
OS.cpp:1835 dtor 2
OS.cpp:1835 dtor 1
OS.cpp:1835 dtor 0
David had hacked in a temporary fix: #if !defined (__Lynx__) || !defined (__powerpc__) // This statement causes a seg fault on ORB shutdown, on LynxOS // 3.0.0/ppc only. delete this->poa_current_; #endif /* ! __Lynx__ || ! __powerpc__ */ This problem was fixed by changes Carlos had made: ChangeLogTag:Thu Aug 31 16:31:04 2000 Carlos O'Ryan <coryan@uci.edu> |