Please report new issues athttps://github.com/DOCGroup
On LynxOS/PPC, the RootPOA test shows the seg fault: Program terminated with signal 11, Segmentation fault. #0 0x10061054 in ACE_Hash_Map_Manager_Ex<TAO_Unbounded_Sequence<unsigned char>, TAO_POA *, TAO_ObjectId_Hash, ACE_Equal_To<TAO_Unbounded_Sequence<unsigned char> >, ACE_Null_Mutex>::close_i () (gdb) where #0 0x10061054 in ACE_Hash_Map_Manager_Ex<TAO_Unbounded_Sequence<unsigned char>, TAO_POA *, TAO_ObjectId_Hash, ACE_Equal_To<TAO_Unbounded_Sequence<unsigned char> >, ACE_Null_Mutex>::close_i () #1 0x10061214 in ACE_Hash_Map_Manager_Ex<TAO_Unbounded_Sequence<unsigned char>, TAO_POA *, TAO_ObjectId_Hash, ACE_Equal_To<TAO_Unbounded_Sequence<unsigned char> >, ACE_Null_Mutex>::open () #2 0x1006f98c in ACE_Hash_Map_Manager_Ex_Adapter<TAO_Unbounded_Sequence<unsigned char>, TAO_POA *, TAO_ObjectId_Hash, ACE_Equal_To<TAO_Unbounded_Sequence<unsigned char> >, ACE_Noop_Key_Generator<TAO_Unbounded_Sequence<unsigned char> > >::ACE_Hash_Map_Manager_Ex_Adapter () #3 0x10026904 in TAO_ORB_Core::~TAO_ORB_Core () #4 0x1002b2c0 in TAO_ORB_Core::fini () #5 0x10002bbc in CORBA_ORB::~CORBA_ORB () #6 0x10008c30 in CORBA_ORB::_decr_refcnt () #7 0x1002d784 in TAO_ORB_Table::~TAO_ORB_Table () #8 0x10032e64 in ACE_Singleton<TAO_ORB_Table, ACE_Thread_Mutex>::~ACE_Singleton () #9 0x10031674 in ACE_Singleton<TAO_ORB_Table, ACE_Thread_Mutex>::cleanup () #10 0x101959e4 in ace_cleanup_destroyer () #11 0x101992b4 in ACE_Object_Manager::fini () #12 0x10198804 in ACE_Object_Manager::~ACE_Object_Manager () #13 0x100010cc in main (argc=0, argv=0x7ffffff8) at RootPOA.cpp:26 #14 0x10243f80 in runmainthread () #15 0x10001048 in __start () VxWorks has a memPartFree on shutdown; may be the same problem.
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>