内存泄漏是一种常见的问题，它会导致程序的内存占用逐渐增加，最终导致系统资源耗尽或程序崩溃。AddressSanitizer (ASan) 和 Valgrind 是很好的内存检测工具，TDengine 的 CI 过程就使用了 ASan 。不过这次内存泄漏问题发生在 Windows 下，我们 CI 暂时还没有覆盖到，因此 TDengine 研发选择使用 Windbg 来解决问题。结果证明，在 Windows 下，使用 Windbg 也是一个不错的选择。
内存泄漏的常用检测方法
内存泄漏通常会发生在以下情况下：
- 程序未正确释放已分配的内存
- 程序中存在循环引用，导致垃圾收集器无法回收内存
- 程序中存在内存泄漏的第三方库或组件
内存泄漏的检测方法主要包括以下几种：
- 静态代码分析工具：未释放的指针或内存分配错误等问题，不能检测在程序运行时动态分配内存的情况。
- 动态分析工具：可以使用内存分配和释放跟踪器来跟踪程序中的内存分配和释放操作，并检测是否存在内存泄漏的情况。然而，使用某些工具（如Valgrind）可能会对程序的性能产生一定的影响。
- 调试器：WinDbg 和 GDB。
优缺点：
- 静态代码分析工具可以在早期发现问题，但是它们不能检测程序运行时动态分配内存的情况。
- 动态分析工具可以在程序运行时检测问题，但是它们可能会影响程序性能，并且在检测大型应用程序时可能需要大量的时间和资源。不过在资源充足的测试环境中跑的话，就都不是问题了，比如 ASan 就帮我们发现过不少问题。
- 调试器可以在程序运行时检测问题，并提供强大的分析工具。
实践分析
基本原理
使用 Windbg 定位内存泄露，依赖 glags 组件记录程序在运行期间所有申请和释放的内存，同时记录的还有申请内存时的调用栈信息。这样在程序运行期间，使用 umdh 组件进行两次快照记录，通过比较两次快照信息的差异，就可以发现两次快照间隔时间段中申请却并未释放的内存申请信息。如果有内存泄露，diff 结果最前边一般就是泄漏点的调用栈信息。当然，两次快照期间，要尽量触发内存泄露，才能更准确的定位。diff 结果中还会有少量正常的申请没来得及释放的调用信息，不过 diff 结果中能看到调用次数，比较容易甄别。
问题介绍
taosdump 在 windows 导入数据出错：
build and install latest TDengine 3.0 branch on Windows
use "taosBenchmark -I stmt -y" to create a lot of tables and data (10000 * 10000).
use "taosdump -D test -o outputFile" to dump out
use "taos -s 'drop database test'" to drop database
use "taosdump -i inputFile" to dump in.错误日志：taosd “tsem_init failed, errno: 28”
Taosdump: dumpInAvroDataImpl() LN7039 taos_stmt_execute() failed! reason: Out of Memory, timestamp: 1500000009256
定位过程
配置 gflags
gflags 工具应该位于路径：C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\gflags，如果没有的话，可以直接前往 Microsoft 的官方网站下载安装：Windows 调试工具 - Windows drivers | Microsoft Learn
安装完成后，在命令行执行 gflags.exe /i your_application.exe 可设置跟踪目标，同时可以设置相关参数。双击运行也是可以的，Image File 对应 /i 参数，选择启动程序 your_application.exe 后先按 tab 键，然后选择其他配置。
定位步骤
1. 启动 your_application.exe（我要调试的是 taosdump.exe，所以下边是 taosdump.exe）
“C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\gflags” -i taosdump.exe +ust
2. 拷贝 pdb 文件到 mysymbols 目录，pdb 文件存储了编译后的程序的调试信息，和可执行程序一起生成，可以在应用程序生成目录中找到。
3. Set pdb 目录
set _NT_SYMBOL_PATH=c:\mysymbols;srv*c:\mycache*https://msdl.microsoft.com/download/symbols4. 生成第一次内存快照
"C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\umdh" -pn:taosdump.exe -f:C:\xstest\umdhlog\taosdump11.log5. 生成第二次内存快照
"C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\umdh" -pn:taosdump.exe -f:C:\xstest\umdhlog\taosdump12.log6. 生成快照比较结果（umdh）
"C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\umdh" C:\xstest\umdhlog\taosdump11.log C:\xstest\umdhlog\taosdump12.log -f:C:\xstest\umdhlog\taosdumpdiff11_12.log分析与解决
结果文件
因为 taosdump 程序启动后直至退出都在做大量的业务工作，内存泄露很容易发生在两次快照期间。 988040 – 6ecf0 表示”申请次数 – 释放次数”， 很明显发生了内存泄露，泄漏点在 buildRequest 函数的 sem_init 这里。
+ 919350 ( 988040 - 6ecf0) 201b0 allocs BackTrace9CB6973F
+ 1ea5c ( 201b0 - 1754) BackTrace9CB6973F allocations
ntdll!RtlpAllocateHeapInternal+948D5
taos!heap_alloc_dbg_internal+1F6 (minkernel\crts\ucrt\src\appcrt\heap\debug_heap.cpp, 359)
taos!heap_alloc_dbg+4D (minkernel\crts\ucrt\src\appcrt\heap\debug_heap.cpp, 450)
taos!_calloc_dbg+6C (minkernel\crts\ucrt\src\appcrt\heap\debug_heap.cpp, 518)
taos!calloc+2E (minkernel\crts\ucrt\src\appcrt\heap\calloc.cpp, 30)
taos!sem_init+5D (C:\workroom\TDengine\contrib\pthread\sem_init.c, 109)
taos!buildRequest+209 (C:\workroom\TDengine\source\client\src\clientImpl.c, 192)
taos!stmtCreateRequest+73 (C:\workroom\TDengine\source\client\src\clientStmt.c, 15)
taos!stmtSetTbName+115 (C:\workroom\TDengine\source\client\src\clientStmt.c, 588)
taos!taos_stmt_set_tbname+7F (C:\workroom\TDengine\source\client\src\clientMain.c, 1350)
taosdump!dumpInAvroDataImpl+E25 (C:\workroom\TDengine\tools\taos-tools\src\taosdump.c, 6260)
taosdump!dumpInOneAvroFile+3D2 (C:\workroom\TDengine\tools\taos-tools\src\taosdump.c, 7229)
taosdump!dumpInAvroWorkThreadFp+20B (C:\workroom\TDengine\tools\taos-tools\src\taosdump.c, 7306)
taosdump!ptw32_threadStart+CD (C:\workroom\TDengine\contrib\pthread\ptw32_threadStart.c, 233)
taosdump!thread_start<unsigned int (__cdecl*)(void *),1>+9C (minkernel\crts\ucrt\src\appcrt\startup\thread.cpp, 97)
KERNEL32!BaseThreadInitThunk+10
ntdll!RtlUserThreadStart+2B泄漏点修改
接下来查看代码并修改，C 语言对内存的使用自由度很高，因此也比较麻烦。可以看到有些路径遗漏了 tsem_destory 的调用。
更加详细的代码方案请见 Fix/xsren/td 21762/sem mem leak by facetosea · Pull Request #19580 · taosdata/TDengine · GitHub
总结
工欲善其事必先利其器，掌握更多的工具和手段，在解决问题时才能比较从容，Windbg 定位内存泄漏的方式非常简单，但是很有效。不过需要注意，它依赖 pdb 文件，因此，发布应用程序时要记得保留 pdb 文件。pdb 文件包含了程序的符号信息，能够帮助我们在调试过程中准确定位问题所在。
另外，从出问题的代码可以看出，这块内存的管理方式还是比较容易出错，RAII 机制能较好的避免资源泄露，C 语言中也可以通过模拟 RAII 来达到类似的效果，虽然没有 C++ 那么流畅，也许以后可以考虑优化一下。
RAII（Resource Acquisition Is Initialization）机制是一种重要的资源管理方式，它将资源的获取和对象的生命周期关联起来。通过在对象的构造函数中获取资源，在析构函数中释放资源，我们可以确保资源的正确管理，防止资源泄漏和内存泄漏等问题。RAII 机制在 C++ 等编程语言中得到广泛应用，是一种有效的资源管理方式。
