| Summary: | Memory leak of TSS created in ORB_init() | ||
|---|---|---|---|
| Product: | TAO | Reporter: | Simon Massey <simon.massey> |
| Component: | ORB | Assignee: | DOC Center Support List (internal) <tao-support> |
| Status: | NEW --- | ||
| Severity: | normal | CC: | iliyan |
| Priority: | P3 | ||
| Version: | 1.6.1 | ||
| Hardware: | All | ||
| OS: | All | ||
I've had another idea that would remove the need to register another native at_exit() just for this instance. Since any other TSS used from within TAO uses the TAO_Singleton_Manager to register the clean up, and this is itself destroyed just before we need the TAO_TSS_Resources to be removed; Why not simply place the following:
delete TAO_TSS_Resources::instance ();
within: TAO/tao/TAO_Singleton_Manager.cpp aprox line 255-266
(which is within TAO_Singleton_Manager::fini()) where it tests for the "real"
singleton_manager and deletes itself with the following code:
// Indicate that this TAO_Singleton_Manager instance has been shut down.
this->object_manager_state_ = OBJ_MAN_SHUT_DOWN;
if (this == the_instance)
the_instance = 0;
if (this->dynamically_allocated_)
{
delete this;
}
return 0;
===============
I.e. like this:
===============
// Indicate that this TAO_Singleton_Manager instance has been shut down.
this->object_manager_state_ = OBJ_MAN_SHUT_DOWN;
if (this == the_instance)
{
the_instance = 0;
delete TAO_TSS_Resources::instance ();
}
if (this->dynamically_allocated_)
{
delete this;
}
return 0;
=================
Would this work? (It is a hack since the destruction relies on the manager which will always be coupled to the original TSS allocation).
Unfortunatly the delete TAO_TSS_Resources::instance (); placed into TAO_Singleton_Manager didn't work as I expected, it didn't seem to be called. (In reply to comment #2) > Unfortunatly the delete TAO_TSS_Resources::instance (); placed into > TAO_Singleton_Manager didn't work as I expected, it didn't seem to be called. Simon, which exe did you valgrind? I'm sorry Lliyan but this was too long ago for me to remember exactly, but it was directly from the doc group scoreboard, and as far as I can tell the problem is still shown here: this one is whilst running TAO/tests/ORB_Local_Config/Bug_1459/run_test.pl http://www.dre.vanderbilt.edu/scoreboard/FC7_Valgrind/2008_03_27_23_02_Full.html#error_132 ==24378== 148 bytes in 1 blocks are definitely lost in loss record 7 of 7 ==24378== at 0x4005436: operator new(unsigned, std::nothrow_t const&) (vg_replace_malloc.c:179) ==24378== by 0x427B50F: ACE_TSS<TAO_TSS_Resources>::make_TSS_TYPE() const (TSS_T.cpp:60) ==24378== by 0x427B6B3: ACE_TSS<TAO_TSS_Resources>::ts_get() const (TSS_T.cpp:219) ==24378== by 0x427B872: TAO_TSS_Singleton<TAO_TSS_Resources, ACE_Thread_Mutex>::instance() (TSS_T.cpp:53) ==24378== by 0x427B2C6: TAO_TSS_Resources::instance() (TSS_Resources.cpp:44) ==24378== by 0x422FA86: TAO_ORB_Core::gui_resource_factory() (ORB_Core.cpp:1513) ==24378== by 0x42174EB: TAO_Leader_Follower::reactor() (Leader_Follower.cpp:135) ==24378== by 0x42305E4: TAO_ORB_Core::reactor() (ORB_Core.cpp:2833) ==24378== by 0x423A2EA: TAO_ORB_Core::init(int&, char**) (ORB_Core.cpp:1151) ==24378== by 0x422D3F4: CORBA::ORB_init(int&, char**, char const*) (ORB.cpp:1350) ==24378== by 0x8048D45: testBug1459(int, char**) (Test.cpp:85) ==24378== by 0x8049251: main (Test.cpp:150) SUCCESS: All tests passed auto_run_tests_finished: TAO/tests/ORB_Local_Config/Bug_1459/run_test.pl Time:4s Result:0 but their are others there such as the one above that one: running TAO/tests/Bug_2702_Regression/run_test.pl http://www.dre.vanderbilt.edu/scoreboard/FC7_Valgrind/2008_03_27_23_02_Full.html#error_126 |
From valgrind: --------------------------------------------------------------------- ==15653== 288 bytes in 1 blocks are definitely lost in loss record 9 of 9 ==15653== at 0x4A06019: operator new(unsigned long) (vg_replace_malloc.c:167) ==15653== by 0x549CB13: ACE_TSS<TAO_TSS_Resources>::make_TSS_TYPE() const (TSS_T.cpp:60) ==15653== by 0x549CC55: ACE_TSS<TAO_TSS_Resources>::ts_get() const (TSS_T.cpp:219) ==15653== by 0x549CCB5: ACE_TSS<TAO_TSS_Resources>::operator TAO_TSS_Resources*() const (TSS_T.cpp:53) ==15653== by 0x54839BD: TAO_TSS_Singleton<TAO_TSS_Resources, ACE_Thread_Mutex>::instance() (TAO_Singleton.cpp:197) ==15653== by 0x5509271: TAO_TSS_Resources::instance() (TSS_Resources.cpp:44) ==15653== by 0x54D8C51: TAO_ORB_Core::gui_resource_factory() (ORB_Core.cpp:1508) ==15653== by 0x54C7634: TAO_Leader_Follower::reactor() (Leader_Follower.cpp:135) ==15653== by 0x54D80B7: TAO_ORB_Core::reactor() (ORB_Core.cpp:2826) ==15653== by 0x54DCFF4: TAO_ORB_Core::init(int&, char**) (ORB_Core.cpp:1144) ==15653== by 0x54D4DFB: CORBA::ORB_init(int&, char**, char const*) (ORB.cpp:1349) ==15653== by 0x40FA81: main (server.cpp:41) ---------------------------------- This is actually caused by the following (as far as I can tell): Basically it is the TAO_TSS_Resource itself that is being leaked and not tidied up. I.e the holder of all of TAO's TSS storage. When ORB_init occurs it first creates it's TAO_TSS_Resource singleton, which (because we are starting up, i.e. orb_init ing) is here: TAO/tao/TAO_Singleton.cpp:158-169 This filename and line number get "confused" by valgrind as it is a template called from in place (TSS_Resources.cpp:44) not as identified by valgrind by: ==15653== by 0x549CCB5: ACE_TSS<TAO_TSS_Resources>::operator TAO_TSS_Resources*() const (TSS_T.cpp:53) (I've seen this misleading placement from valgrind before with inline and/or template code). The comment is very enlighting..... if (TAO_Singleton_Manager::starting_up () || TAO_Singleton_Manager::shutting_down ()) { // The program is still starting up, and therefore assumed // to be single threaded. There's no need to double-check. // Or, the TAO_Singleton_Manager instance has been destroyed, // so the preallocated lock is not available. Either way, // don't register for destruction with the // TAO_Singleton_Manager: we'll have to leak this instance. ACE_NEW_RETURN (singleton, (TAO_TSS_Singleton<TYPE, ACE_LOCK>), 0); } else ... The else clause registers the at_exit() clean up routine for the singletons created later, but because we are starting up the singleton manager is not yet active. (Or so I beleive based upon the comment above). Hence we leak the TSS_Resource. (Purhaps we can create a "native" at_exit() cleanup for this entry?) Do you have any ideas about this?