用 valgrind 检查发现内存泄漏-TC_Thread::start()

[duansumin2022]

TARS_VERSION: 3.0.1
client端valgrind 检查发现内存泄漏，valgrin报告：

==95540==
==95540== HEAP SUMMARY:
==95540== in use at exit: 944 bytes in 4 blocks
==95540== total heap usage: 97,080 allocs, 97,076 frees, 21,879,065 bytes allocated
==95540==
==95540== 592 bytes in 1 blocks are possibly lost in loss record 4 of 4
==95540== at 0x4C2C089: calloc (vg_replace_malloc.c:762)
==95540== by 0x40126C4: allocate_dtv (dl-tls.c:317)
==95540== by 0x40126C4: _dl_allocate_tls (dl-tls.c:533)
==95540== by 0x674A7AB: allocate_stack (allocatestack.c:539)
==95540== by 0x674A7AB: pthread_create@@GLIBC_2.2.5 (pthread_create.c:447)
==95540== by 0x5C0A596: __gthread_create (gthr-default.h:662)
==95540== by 0x5C0A596: std::thread::_M_start_thread(std::shared_ptrstd::thread::_Impl_base) (thread.cc:142)
==95540== by 0x552E6B1: std::thread::thread<void ()(tars::TC_Thread), tars::TC_Thread* const>(void (&&)(tars::TC_Thread), tars::TC_Thread* const&&) (thread:135)
==95540== by 0x552D83C: tars::TC_Thread::start() (tc_thread.cpp:145)
==95540== by 0x553736D: tars::TC_TimeProvider::getInstance()::{lambda()#1}::operator()() const (tc_timeprovider.cpp:32)
==95540== by 0x5537B7F: void std::_Bind_simple<tars::TC_TimeProvider::getInstance()::{lambda()#1} ()>::_M_invoke<>(std::_Index_tuple<>) (functional:1732)
==95540== by 0x5537B20: std::_Bind_simple<tars::TC_TimeProvider::getInstance()::{lambda()#1} ()>::operator()() (functional:1720)
==95540== by 0x5537A4A: void std::__once_call_impl<std::_Bind_simple<tars::TC_TimeProvider::getInstance()::{lambda()#1} ()> >() (mutex:754)
==95540== by 0x674EE3F: pthread_once (pthread_once.S:103)
==95540== by 0x5537324: __gthread_once(int*, void (*)()) (gthr-default.h:699)
==95540==
==95540== LEAK SUMMARY:
==95540== definitely lost: 0 bytes in 0 blocks
==95540== indirectly lost: 0 bytes in 0 blocks
==95540== possibly lost: 592 bytes in 1 blocks
==95540== still reachable: 352 bytes in 3 blocks
==95540== suppressed: 0 bytes in 0 blocks
==95540== Reachable blocks (those to which a pointer was found) are not shown.
==95540== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==95540==
==95540== For lists of detected and suppressed errors, rerun with: -s
==95540== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

[ruanshudong]

这个获取时间是常驻的, 全进程就一个, 所以就没有做释放.

[duansumin2022]

这个获取时间是常驻的, 全进程就一个, 所以就没有做释放.
反复测试client端sdk的初始化和释放，发现内存一直在增长，用valgrind 检测这个demo程序，报告又只涉及获取时间这么一个地方。
SR_InitAgentCommEnv主要是tars::Communicator 、ServantPrx 资源的创建；SR_UnInitAgentCommEnv则是这些资源的释
放。

请问TLOGXXX写日志，程序内存会增长吗？

while(1){

	ret = SR_InitAgentCommEnv(3, SN,  snlen,(unsigned char*)config_file.data());
	if(ret != 0){
		cout << "SR_InitAgentCommEnv error errcode=" << ret << endl;
		return 0;
	}
	cout << "SR_InitAgentCommEnv seccuss " << endl;
	std::this_thread::sleep_for(std::chrono::seconds(2));
	ret = SR_UnInitAgentCommEnv();
	if(ret != 0){
		cout << "SR_UnInitAgentCommEnv error errcode=" << ret << endl;
	} else {
		cout << "SR_UnInitAgentCommEnv seccuss " << endl;
	}
	std::this_thread::sleep_for(std::chrono::seconds(2));
}

[ruanshudong]

tars::Communicator 这个原则上只需要全局初始化一个的, 不需要搞很个
另外TLOGXXX如果你写得很快, 导致落地硬盘慢, 就可能在内存中堆积, 实际业务中不太可能发生吧.

[duansumin2022]

tars::Communicator 这个原则上只需要全局初始化一个的, 不需要搞很个

Communicator用的是指针 tars::Communicator* ，放到一个全局结构题里面，sdk初始化的时候new 一个tars::Communicator ，主要是想将其传入多个server对象中去分别创建多个ServantPrx。sdk资源释放的时候，detele tars::Communicator* 指针变量

另外TLOGXXX如果你写得很快, 导致落地硬盘慢, 就可能在内存中堆积, 实际业务中不太可能发生吧.

我再看看是不是其他地方有泄漏

谢谢