Please report new issues athttps://github.com/DOCGroup
ACE VERSION: 5.5.8 HOST MACHINE and OPERATING SYSTEM: Linux zaphod 2.6.15-28-amd64-generic #1 SMP PREEMPT Tue Mar 13 20:51:52 UTC 2007 x86_64 GNU/Linux TARGET MACHINE and OPERATING SYSTEM, if different from HOST: COMPILER NAME AND VERSION (AND PATCHLEVEL): gcc (GCC) 4.1.2 THE $ACE_ROOT/ace/config.h FILE [if you use a link to a platform- specific file, simply state which one]: #define ACE_HAS_XML_SVC_CONF // workaround for bug in gcc 4.0.x #define ACE_LACKS_PRAGMA_ONCE #include "ace/config-linux.h" THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE [if you use a link to a platform-specific file, simply state which one (unless this isn't used in this case, e.g., with Microsoft Visual C++)]: # configure ACE/TAO for our use templates=automatic debug=1 optimize=1 exceptions=1 threads=1 inline=1 rtti=1 versioned_so=1 ssl=1 #no_hidden_visibility=1 # Disable the RCSID for release/non-debug builds. CPPFLAGS += -DACE_USE_RCSID=0 CC = /opt2/linux/ix86/x86_64-pc-linux-gnu/bin/gcc CXX = /opt2/linux/ix86/x86_64-pc-linux-gnu/bin/g++ CFLAGS += -m64 -I/opt2/linux/x86_64/include CCFLAGS += -m64 -I/opt2/linux/x86_64/include LDFLAGS += -m64 -I/opt2/linux/x86_64/include -L/opt2/linux/x86_64/lib TAO_IDL_PREPROCESSOR = /opt2/linux/ix86/x86_64-pc-linux-gnu/bin/gcc include $(ACE_ROOT)/include/makeinclude/platform_linux.GNU CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features (used by MPC when you generate your own makefiles): AREA/CLASS/EXAMPLE AFFECTED: TAO_CosNotification / ORB DOES THE PROBLEM AFFECT: EXECUTION? after loading and unloading TAO_CosNotification orb shutdown hangs SYNOPSIS: testcase is attached DESCRIPTION: testcase loads dynamically the ORB and TAO_CosNotification testcase tries to unload TAO_CosNotification and the ORB testcase hangs in ORB shutdown REPEAT BY: [What you did to get the error; include test program or session transcript if at all possible. ] SAMPLE FIX/WORKAROUND: none known This is a regression to TAO 1.5.1
Created attachment 781 [details] regression test (.tar.gz) the regression test
I have the same blocking situation in another context (where I can not easily create a test for) As you can see that in both cases the ORB thread is still in ORB::run while the other thread is waiting on some mutex. Could it be that there is some race condition on a mutex wait with shutting down the ORB? This is the gdb trace of the bug2926 executable: 0x00002aaaacfe5ecb in __lll_mutex_lock_wait () from /lib/libpthread.so.0 (gdb) info threads 2 Thread 1082132832 (LWP 18543) 0x00002aaaad748d76 in select () from /lib/libc.so.6 1 Thread 46912544458336 (LWP 18542) 0x00002aaaacfe5ecb in __lll_mutex_lock_wait () from /lib/libpthread.so.0 (gdb) where #0 0x00002aaaacfe5ecb in __lll_mutex_lock_wait () from /lib/libpthread.so.0 #1 0x00002aaaad8c4660 in ?? () #2 0x0000000000000030 in ?? () #3 0x00002aaaacfe2d06 in pthread_mutex_lock () from /lib/libpthread.so.0 #4 0x00000000ffffffff in ?? () #5 0x00002aaaacce7110 in ACE_Service_Repository::find (this=0x1, name=0x7fffffdb1ef0 "�=a", srp=0x1, ignore_suspended=true) at OS_NS_Thread.inl:3660 #6 0x000000000054d180 in ?? () #7 0x0000000000000001 in ?? () #8 0x0000000000000001 in ?? () #9 0x0000000000000001 in ?? () #10 0x00002aaaac35720a in TAO_Root_POA::check_for_valid_wait_for_completions ( orb_core=@0x54d180, wait_for_completion=false) at PortableServer/Root_POA.cpp:1192 #11 0x00002aaaac32df97 in TAO_Object_Adapter::close (this=0x2aaaacd33086, wait_for_completion=5559360) at Guard_T.inl:12 #12 0x00002aaaaca60624 in TAO_Adapter_Registry::close (this=0x54d440, wait_for_completion=1) at Adapter_Registry.cpp:45 #13 0x00002aaaacab5019 in TAO_ORB_Core::shutdown (this=0x54d180, wait_for_completion=true) at ORB_Core.cpp:2310 #14 0x0000000000403dc0 in DllORB::fini (this=0x54c7c0) at DllORB.cpp:146 #15 0x00002aaaacce7c3b in ACE_Service_Object_Type::fini ( this=<value optimized out>) at Service_Types.cpp:129 #16 0x00002aaaacce5fd2 in ACE_Service_Type::fini (this=0x54c880) at Service_Object.cpp:105 #17 0x00002aaaacce6006 in ~ACE_Service_Type (this=0x55e288) at Service_Object.cpp:81 #18 0x00002aaaacce6c64 in ACE_Service_Repository::remove ( this=<value optimized out>, name=0x616770 "testDllOrb", ps=0x0) at Service_Repository.cpp:467 #19 0x00002aaaad8cdd61 in ACEXML_Svcconf_Handler::startElement (this=0x613cd0, qName=<value optimized out>, alist=<value optimized out>) at Svcconf_Handler.cpp:479 #20 0x00002aaaad9da9c6 in ACEXML_Parser::parse_element (this=0x613b48, is_root=<value optimized out>) at Parser.cpp:900 #21 0x00002aaaad9dada6 in ACEXML_Parser::parse_content (this=0x613b48, startname=0x613db0 "ACE_Svc_Conf", ns_uri=@0x7fffffdb2018, ns_lname=@0x7fffffdb2010, ns_flag=0) at Parser.cpp:1093 ---Type <return> to continue, or q <return> to quit--- #22 0x00002aaaad9da9dd in ACEXML_Parser::parse_element (this=0x613b48, is_root=<value optimized out>) at Parser.cpp:985 #23 0x00002aaaad9de51a in ACEXML_Parser::parse (this=0x613b48, input=<value optimized out>) at Parser.cpp:225 #24 0x00002aaaad8c87b3 in ACEXML_Svcconf_Parser::parse_string (this=0x613b40, str=<value optimized out>) at Svcconf.cpp:99 #25 0x00002aaaacce2731 in ACE_Service_Gestalt::process_directive ( this=0x5075d8, directive=0x405710 "<ACE_Svc_Conf><remove id=\"testDllOrb\"></remove></ACE_Svc_Conf>") at Service_Gestalt.cpp:979 #26 0x0000000000404a5d in loadunloadcycle () at Service_Config.inl:142 #27 0x0000000000404c30 in main (argc=<value optimized out>, argv=<value optimized out>) at bug2926.cpp:138 (gdb) (gdb) thread 2 [Switching to thread 2 (Thread 1082132832 (LWP 18543))]#0 0x00002aaaad748d76 in select () from /lib/libc.so.6 (gdb) where #0 0x00002aaaad748d76 in select () from /lib/libc.so.6 #1 0x00002aaaaccfa314 in ACE_Select_Reactor_T<ACE_Reactor_Token_T<ACE_Token> >::wait_for_multiple_events (this=0x55d010, dispatch_set=@0x55d558, max_wait_time=0x0) at OS_NS_sys_select.inl:49 #2 0x00002aaaacd6b718 in ACE_TP_Reactor::dispatch_i (this=0x8, max_wait_time=0x55d568, guard=@0x0) at TP_Reactor.cpp:182 #3 0x00002aaaacd6b856 in ACE_TP_Reactor::handle_events (this=0x55d010, max_wait_time=0x0) at TP_Reactor.cpp:174 #4 0x00002aaaacab35a9 in TAO_ORB_Core::run (this=0x54d180, tv=0x0, perform_work=0) at ORB_Core.cpp:2239 #5 0x00000000004034f9 in DllORB::svc (this=0x54c7c0) at DllORB.cpp:219 #6 0x00002aaaacd62d3b in ACE_Task_Base::svc_run (args=<value optimized out>) at Task.cpp:271 #7 0x00002aaaacd638b7 in ACE_Thread_Adapter::invoke (this=0x586790) at Thread_Adapter.cpp:95 #8 0x00002aaaacfe10fa in start_thread () from /lib/libpthread.so.0 #9 0x00002aaaad74fce2 in clone () from /lib/libc.so.6 #10 0x0000000000000000 in ?? () Here's the gdb stack for my other rproblem: 0x00002aaaad143ecb in __lll_mutex_lock_wait () from /lib/libpthread.so.0 (gdb) where #0 0x00002aaaad143ecb in __lll_mutex_lock_wait () from /lib/libpthread.so.0 #1 0x00002aaab27478a0 in ?? () #2 0x0000000000000060 in ?? () #3 0x00002aaaad140d06 in pthread_mutex_lock () from /lib/libpthread.so.0 #4 0x0000000000556730 in ?? () #5 0x0000000000000000 in ?? () (gdb) info threads 2 Thread 1082132832 (LWP 18121) 0x00002aaaadb66d76 in select () from /lib/libc.so.6 1 Thread 46912626784416 (LWP 18119) 0x00002aaaad143ecb in __lll_mutex_lock_wait () from /lib/libpthread.so.0 (gdb) thread 2 [Switching to thread 2 (Thread 1082132832 (LWP 18121))]#0 0x00002aaaadb66d76 in select () from /lib/libc.so.6 (gdb) where #0 0x00002aaaadb66d76 in select () from /lib/libc.so.6 #1 0x00002aaaacbf9314 in ACE_Select_Reactor_T<ACE_Reactor_Token_T<ACE_Token> >::wait_for_multiple_events (this=0x5d8ed0, dispatch_set=@0x5d9418, max_wait_time=0x0) at OS_NS_sys_select.inl:49 #2 0x00002aaaacc6a718 in ACE_TP_Reactor::dispatch_i (this=0x9, max_wait_time=0x5d9428, guard=@0x0) at TP_Reactor.cpp:182 #3 0x00002aaaacc6a856 in ACE_TP_Reactor::handle_events (this=0x5d8ed0, max_wait_time=0x0) at TP_Reactor.cpp:174 #4 0x00002aaab0b7a5a9 in TAO_ORB_Core::run (this=0x5a6e30, tv=0x0, perform_work=0) at ORB_Core.cpp:2239 #5 0x00002aaaac80e698 in tradescape::utility::DllOrb::svc (this=0x542d50) at src/corbautility/DllOrb.cpp:313 #6 0x00002aaaacc61d3b in ACE_Task_Base::svc_run (args=<value optimized out>) at Task.cpp:271 #7 0x00002aaaacc628b7 in ACE_Thread_Adapter::invoke (this=0x5c0e40) at Thread_Adapter.cpp:95 #8 0x00002aaaad13f0fa in start_thread () from /lib/libpthread.so.0 #9 0x00002aaaadb6dce2 in clone () from /lib/libc.so.6 #10 0x0000000000000000 in ?? ()
Lothar, can you maybe test with the plain svc.conf, then we at least know whether the problem is related to the xml svc.conf or general in nature
It would take me a long time, as I have to build a complete new ACE/TAO. It would be much faster if someone already having built a "regular svc.conf" build just builds the attached test (it comes with a MPC file and should compile out of the box) I will see if I can spare the time to do that rebuild, but I can not tell when I will have time to do it.
mine
merging test into my tree
also reproducable without xml based service config, call stack below 004BF40B ACE_Thread_Mutex::acquire(this=:01190370) 0076B442 ACE_Lock_Adapter<ACE_Thread_Mutex>::acquire(this=:01172D08) 00762FA0 TAO::Portable_Server::Non_Servant_Upcall::~Non_Servant_Upcall(this=:0012F4D4) 00798B54 TAO::Portable_Server::RequestProcessingStrategyAOMOnly::cleanup_servant(this=:011A3EE0, servant=:01192C10, user_id=:011A844C) 0079295D TAO_Root_POA::cleanup_servant(this=:011924EC, servant=:01192C10, user_id=:011A844C) 007A00C3 TAO::Portable_Server::ServantRetentionStrategyRetain::deactivate_map_entry(this=:01191E3C, active_object_map_entry=:011A844C) 007A0A74 TAO::Portable_Server::ServantRetentionStrategyRetain::deactivate_all_objects(this=:01191E3C) 007921E2 TAO_Root_POA::deactivate_all_objects_i(this=:011924EC, etherealize_objects=true) 00792053 TAO_Root_POA::deactivate_all_objects_i(this=:011924EC, etherealize_objects=true, wait_for_completion=true) 00781140 TAO_POA_Manager::deactivate_i(this=:01191D90, etherealize_objects=true, wait_for_completion=true) 007806AF TAO_POA_Manager::deactivate(this=:01191D90, etherealize_objects=true, wait_for_completion=true) 003F22F7 DllORB::fini(this=:01172A40) 004A71BB ACE_Service_Object_Type::fini(this=:01172ACC) 004A5A99 ACE_Service_Type::fini(this=:01172AF8) 004A5A23 ACE_Service_Type::~ACE_Service_Type(this=:01172AF8) 004A6CF4 ACE_Service_Repository::remove(this=:011668A8, name=:011A842C, ps=NULL) 004A3049 ACE_Service_Gestalt::remove(this=:0116682C, svc_name=:011A842C) 00486310 ACE_Remove_Node::apply(this=:011DAE78, config=:0116682C, yyerrno=:0012FDAC) 004B6040 ace_yyparse(ace_svc_conf_parameter=:0012FDA4) 004A3377 ACE_Service_Gestalt::process_directives_i(this=:0116682C, param=:0012FDA4) 004A3754 ACE_Service_Gestalt::process_directive(this=:0116682C, directive=:00404324) 0049E30D ACE_Service_Config::process_directive(directive=:00404324) 004016AB loadunloadcycle() 0040205C ace_main_i( =1, =:0116A2BC) 004025D6 ACE_Main::run_i(this=:0012FF88, argc=1, argv=:0116A2BC) 004795D5 ACE_Main_Base::run(this=:0012FF88, argc=1, argv=:0116A2BC) 00401F57 main(argc=1, argv=:0116A2BC) 3267E552 C:\PROGRA~1\Borland\CBUILD~1\Bin\CC3260MT.DLL
found the problem, fix ready locally, but want to first add the test to the repo to reproduce it on head
Mon Jul 2 07:31:12 UTC 2007 Johnny Willemsen <jwillemsen@remedy.nl> * orbsvcs/orbsvcs/Event/EC_ObserverStrategy.cpp: Initialise pointer with 0 * orbsvcs/orbsvcs/FaultTolerance/FT_ClientORBInitializer.cpp: Layout changes * orbsvcs/tests/Bug_2926_Regression/*: New regression test for bug 2926. Thanks to Lothar Werzingen <lothar at tradescape dot biz> for reporting this issue * orbsvcs/PortableServer/POAManager.inl: Fix bug 2926.
reopen, regression works on windows but crashes on exit on linux
Looks a problem in the notification service properties, see the callstack below. Program received signal SIGABRT, Aborted. [Switching to Thread -1223682384 (LWP 9206)] 0xffffe410 in __kernel_vsyscall () (gdb) back #0 0xffffe410 in __kernel_vsyscall () #1 0xb712c7d0 in raise () from /lib/libc.so.6 #2 0xb712dea3 in abort () from /lib/libc.so.6 #3 0xb730a3a0 in __gnu_cxx::__verbose_terminate_handler () from /usr/lib/libstdc++.so.6 #4 0xb7307dc5 in std::set_unexpected () from /usr/lib/libstdc++.so.6 #5 0xb7307e02 in std::terminate () from /usr/lib/libstdc++.so.6 #6 0xb73084e5 in __cxa_pure_virtual () from /usr/lib/libstdc++.so.6 #7 0xb76d3e85 in CORBA::release (obj=0x6) at /home/build/ACE/gcc/ACE_wrappers/TAO/tao/AnyTypeCode/TypeCode.inl:17 #8 0xb78ecd0b in TAO::Any_Dual_Impl_T<NotifyExt::ThreadPoolParams>::free_value (this=0x805b5b0) at /home/build/ACE/gcc/ACE_wrappers/TAO/tao/AnyTypeCode/Any_Dual_Impl_T.cpp:197 #9 0xb76a6371 in TAO::Any_Impl::_remove_ref (this=0x805b5b0) at AnyTypeCode/Any_Impl.cpp:104 #10 0xb76a0177 in ~Any (this=0x807b150) at AnyTypeCode/Any.cpp:49 #11 0xb7887d6e in ~PropertySeq (this=0x807b28c) at CosNotificationC.h:158 #12 0xb7df1788 in ~TAO_Notify_Properties (this=0x807b244) at Notify/Properties.cpp:44 #13 0xb7df1bf3 in ~TAO_Singleton (this=0x807b240) at /home/build/ACE/gcc/ACE_wrappers/TAO/tao/TAO_Singleton.h:48 #14 0xb7df19e1 in TAO_Singleton<TAO_Notify_Properties, ACE_Thread_Mutex>::cleanup (this=0x6) at /home/build/ACE/gcc/ACE_wrappers/TAO/tao/TAO_Singleton.cpp:107 #15 0xb7432c68 in ace_cleanup_destroyer (object=0x807b240, param=0x0) at Cleanup.cpp:33 #16 0xb7432e9d in ACE_OS_Exit_Info::call_hooks (this=0x805ca40) at Cleanup.cpp:183 #17 0xb76133d3 in TAO_Singleton_Manager::fini (this=0x805ca28) at TAO_Singleton_Manager.cpp:232 #18 0xb7613969 in TAO_SINGLETON_MANAGER_CLEANUP_DESTROYER_NAME () at TAO_Singleton_Manager.cpp:40 #19 0xb7432e5c in ACE_OS_Exit_Info::call_hooks (this=0x804b138) at Cleanup.cpp:188 #20 0xb7464449 in ACE_Object_Manager::fini (this=0x804b128) at Object_Manager.cpp:609 #21 0xb74646a7 in ~ACE_Object_Manager (this=0x804b128) at Object_Manager.cpp:318 #22 0xb7464205 in ~ACE_Object_Manager_Manager (this=0xb7504b70) at Object_Manager.cpp:765 #23 0xb7464240 in __tcf_0 () at Object_Manager.cpp:773 #24 0xb712f566 in __cxa_finalize () from /lib/libc.so.6 #25 0xb73ee883 in __do_global_dtors_aux () from /home/build/ACE/gcc/ACE_wrappers/lib/libACE.so.5.5.9 #26 0xb74b8abc in _fini () from /home/build/ACE/gcc/ACE_wrappers/lib/libACE.so.5.5.9 #27 0xb7f66dc5 in _dl_fini () from /lib/ld-linux.so.2 #28 0xb712f26d in exit () from /lib/libc.so.6 #29 0xb7119884 in __libc_start_main () from /lib/libc.so.6 #30 0x080490d1 in _start () (gdb) q
Thu Jul 5 18:50:00 UTC 2007 Johnny Willemsen <jwillemsen@remedy.nl> * orbsvcs/Notify_Service/Notify_Server.cpp: * orbsvcs/orbsvcs/Notify/Properties.cpp: * orbsvcs/orbsvcs/Notify/Properties.h: Make the protocols an unmanages singleton and leak them at process exit. When loading the notification service as dll it can happen that we unload it after the unload of the anytypecode library and when we get a crash. The only solution that works when making a dll or an exe is to leak the singleton. Thanks to Chad Elliot for testing some patches and giving his insights in why things crash.