| Summary: | Service gestalt leads to lot of memory leaks | ||
|---|---|---|---|
| Product: | ACE | Reporter: | Johnny Willemsen <jwillemsen> |
| Component: | ACE Core | Assignee: | DOC Center Support List (internal) <tao-support> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | ||
| Priority: | P1 | ||
| Version: | 5.6.1 | ||
| Hardware: | All | ||
| OS: | All | ||
| Bug Depends on: | 2980 | ||
| Bug Blocks: | 3129 | ||
| Attachments: |
Valgrind log
Logging with ACE_DEBUG enabled The valgrind log I mentioned above |
||
|
Description
Johnny Willemsen
2007-10-24 07:58:39 CDT
found on solaris, maybe more generic in nature regression test is in the repository Regression is in svn, when run on linux with valgrind enabled I do see the same issue, we leak a lot of memory. ==4583== 368,640 bytes in 45 blocks are indirectly lost in loss record 10 of 10 ==4583== at 0x4A055F6: operator new[](unsigned long, std::nothrow_t const&) (vg_replace_malloc.c:211) ==4583== by 0x4FFC1C7: ACE_Service_Repository::open(unsigned long) (Service_Repository.cpp:114) ==4583== by 0x4FFC240: ACE_Service_Repository::ACE_Service_Repository(unsigned long) (Service_Repository.cpp:128) ==4583== by 0x4FF7C3F: ACE_Service_Gestalt::init_i() (Service_Gestalt.cpp:269) ==4583== by 0x4FF7CFC: ACE_Service_Gestalt::ACE_Service_Gestalt(unsigned long, bool, bool) (Service_Gestalt.cpp:246) ==4583== by 0x4FF6D48: ACE_TSS<ACE_Service_Gestalt>::make_TSS_TYPE() const (TSS_T.cpp:60) ==4583== by 0x4FF21A2: ACE_TSS<ACE_Service_Gestalt>::ts_get() const (TSS_T.cpp:219) ==4583== by 0x4FF698B: ACE_Service_Config_Guard::ACE_Service_Config_Guard(ACE_Service_Gestalt*) (TSS_T.cpp:53) ==4583== by 0x4CB08D2: TAO::Invocation_Adapter::invoke_i(TAO_Stub*, TAO_Operation_Details&) (Invocation_Adapter.cpp:61) ==4583== by 0x4CB0591: TAO::Invocation_Adapter::invoke(TAO::Exception_Data*, unsigned long) (Invocation_Adapter.cpp:50) ==4583== by 0x40429E: test::test_method() (testC.cpp:130) ==4583== by 0x40367C: Client::svc() (client.cpp:65) ==4583== by 0x5076A76: ACE_Task_Base::svc_run(void*) (Task.cpp:271) ==4583== by 0x50775E6: ACE_Thread_Adapter::invoke() (Thread_Adapter.cpp:95) ==4583== by 0x3C744061B4: start_thread (in /lib64/libpthread-2.5.so) ==4583== by 0x3C738CD39C: clone (in /lib64/libc-2.5.so) Created attachment 858 [details]
Valgrind log
Output when bug_3108_regression is run using valgrind
Created attachment 864 [details]
Logging with ACE_DEBUG enabled
By commenting out the following code in ace/Service_Config.h the leak is gone:
template<> inline void
ACE_TSS<ACE_Service_Gestalt>::cleanup (void*ptr)
{
// Borland C++ 2007 *needs* the parameter
// name, but it is not clear why ...
ACE_UNUSED_ARG (ptr);
}
Thu Nov 1 11:11:15 UTC 2007 Johnny Willemsen <jwillemsen@remedy.nl> * ace/Service_Config.h: Removed the patch for bugzilla 2980, this results in a memory leak of 10Kb for each thread that uses the ACE_Service_Config_Guard. This memory leak is documented in bugzilla 3108. For bugzilla 2980 we need to have a different patch without reintroducing the memory leak. reopening, patch reverted seems not to be complete Revised reverted patch is committed Fri Nov 2 07:48:15 UTC 2007 Johnny Willemsen <jwillemsen@remedy.nl> * ace/Service_Config.{h,cpp}: Removed the patch for bugzilla 2980, this results in a memory leak of 10Kb for each thread that uses the ACE_Service_Config_Guard. This memory leak is documented in bugzilla 3108. For bugzilla 2980 we need to have a different patch without reintroducing the memory leak. As a result of the removal of the noop specialization the number of memory leaks in our valgrind daily build dropped from 3462 to 2805 memory leaks. See http://www.dre.vanderbilt.edu/~isisbuilds/auto_compile_logs/blade55/valgrind/index.html now fixed again reopen, with the full patch the number of leaks did increase again (In reply to comment #12) > reopen, with the full patch the number of leaks did increase again > Hi Johnny, It seems your solution worked, at least as far as the thread-per-connection SC-related leaks are concerned. I am looking into another solution for 2980 and I decided to check TAO/tests/Bug_3108_Regression, just in case. Valgrind did detect memory leaks but none of them are related to the Service Configuration (see the full log attached below) ... ==13733== 1 bytes in 1 blocks are definitely lost in loss record 1 of 9 ==13733== at 0x402274D: operator new(unsigned, std::nothrow_t const&) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==13733== by 0x44621A5: ACE_TSS<ACE_Dynamic>::make_TSS_TYPE() const (TSS_T.cpp:60) ==13733== by 0x44627F8: ACE_TSS<ACE_Dynamic>::ts_get() const (TSS_T.cpp:219) ==13733== by 0x4462880: ACE_TSS<ACE_Dynamic>::operator ACE_Dynamic*() const (TSS_T.cpp:53) ==13733== by 0x4462A78: ACE_TSS_Singleton<ACE_Dynamic, ACE_Null_Mutex>::instance() (Singleton.cpp:292) ==13733== by 0x446211C: ACE_Dynamic::instance() (Dynamic.cpp:26) ==13733== by 0x4280324: ACE_Svc_Handler<ACE_SOCK_Stream, ACE_NULL_SYNCH>::operator new(unsigned, std::nothrow_t const&) (Svc_Handler.cpp:72) ==13733== by 0x4289543: TAO_Creation_Strategy<TAO_IIOP_Connection_Handler>::make_svc_handler(TAO_IIOP_Connection_Handler*&) (Acceptor_Impl.cpp:50) ==13733== by 0x428918E: ACE_Strategy_Acceptor<TAO_IIOP_Connection_Handler, ACE_SOCK_Acceptor>::make_svc_handler(TAO_IIOP_Connection_Handler*&) (Acceptor.cpp:749) ==13733== by 0x428B1A8: ACE_Acceptor<TAO_IIOP_Connection_Handler, ACE_SOCK_Acceptor>::handle_input(int) (Acceptor.cpp:383) ==13733== by 0x44E545C: ACE_TP_Reactor::dispatch_socket_event(ACE_EH_Dispatch_Info&) (TP_Reactor.cpp:591) ==13733== by 0x44E5583: ACE_TP_Reactor::handle_socket_events(int&, ACE_TP_Token_Guard&) (TP_Reactor.cpp:460) ==13733== ==13733== ==13733== 36 bytes in 1 blocks are definitely lost in loss record 5 of 9 ==13733== at 0x402274D: operator new(unsigned, std::nothrow_t const&) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==13733== by 0x42CB4EF: ACE_TSS<TAO_ORB_Core_TSS_Resources>::make_TSS_TYPE() const (TSS_T.cpp:60) ==13733== by 0x42CBC40: ACE_TSS<TAO_ORB_Core_TSS_Resources>::ts_get() const (TSS_T.cpp:219) ==13733== by 0x42CBCC8: ACE_TSS<TAO_ORB_Core_TSS_Resources>::operator TAO_ORB_Core_TSS_Resources*() const (TSS_T.cpp:53) ==13733== by 0x42C907B: TAO_ORB_Core::get_tss_resources() (ORB_Core.inl:259) ==13733== by 0x42A03E6: TAO_Leader_Follower::get_tss_resources() const (Leader_Follower.inl:30) ==13733== by 0x42A142A: TAO_Leader_Follower::set_event_loop_thread(ACE_Time_Value*) (Leader_Follower.inl:70) ==13733== by 0x42A355F: TAO_LF_Strategy_Complete::set_event_loop_thread(ACE_Time_Value*, TAO_Leader_Follower&) (LF_Strategy_Complete.cpp:31) ==13733== by 0x42A2859: TAO_LF_Event_Loop_Thread_Helper::TAO_LF_Event_Loop_Thread_Helper(TAO_Leader_Follower&, TAO_LF_Strategy&, ACE_Time_Value*) (LF_Event_Loop_Thread_Helper.inl:16) ==13733== by 0x42C2B23: TAO_ORB_Core::run(ACE_Time_Value*, int) (ORB_Core.cpp:2115) ==13733== by 0x42BC068: CORBA::ORB::run(ACE_Time_Value*) (ORB.cpp:202) ==13733== by 0x42BC0BE: CORBA::ORB::run() (ORB.cpp:188) ==13733== ==13733== ==13733== 148 bytes in 1 blocks are definitely lost in loss record 9 of 9 ==13733== at 0x402274D: operator new(unsigned, std::nothrow_t const&) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==13733== by 0x430CA75: ACE_TSS<TAO_TSS_Resources>::make_TSS_TYPE() const (TSS_T.cpp:60) ==13733== by 0x430C77A: ACE_TSS<TAO_TSS_Resources>::ts_get() const (TSS_T.cpp:219) ==13733== by 0x430C802: ACE_TSS<TAO_TSS_Resources>::operator TAO_TSS_Resources*() const (TSS_T.cpp:53) ==13733== by 0x430CA38: TAO_TSS_Singleton<TAO_TSS_Resources, ACE_Thread_Mutex>::instance() (TAO_Singleton.cpp:197) ==13733== by 0x430BF16: TAO_TSS_Resources::instance() (TSS_Resources.cpp:44) ==13733== by 0x42BFA86: TAO_ORB_Core::gui_resource_factory() (ORB_Core.cpp:1508) ==13733== by 0x429FC06: TAO_Leader_Follower::reactor() (Leader_Follower.cpp:135) ==13733== by 0x42C27CA: TAO_ORB_Core::reactor() (ORB_Core.cpp:2826) ==13733== by 0x42C866A: TAO_ORB_Core::init(int&, char**) (ORB_Core.cpp:1144) ==13733== by 0x42BDBEB: CORBA::ORB_init(int&, char**, char const*) (ORB.cpp:1350) ==13733== by 0x804D08E: main (server.cpp:41) ... Since the original problem that prompted re-opening of this ticket has been resolved, I propose to close the ticket. If you think these leaks are new it may be best to create a new ticket that will better represent what is going on. Created attachment 865 [details]
The valgrind log I mentioned above
I agree that the leaks to this change are gone, but I think some others are introduced by Simon. Closing this one for now, contacted Simon for the others On the scoreboard now TAO/orbsvcs/tests/unit/Notify/MC/Control is failing. The drop is from nov 1, so I wonder if that is caused by this change added a new issue for the MC crash, the memory leak itself is gone |