Question

我从libuv-book https://nikhilm.github.io/uvbook/basics.html获取了代码片段，并使用下一个简单代码测试了内存泄漏：

#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>  
#include <crtdbg.h>  
#include <stdio.h>
#include <uv.h>


int TestMemLeakage_uv_loop() 
{
   uv_loop_t *loop = (uv_loop_t*)malloc(sizeof(uv_loop_t));
   uv_loop_init(loop);

   printf("Now quitting.\n");
   uv_run(loop, UV_RUN_DEFAULT);

   uv_loop_close(loop);
   free(loop);
   return 0;
}

void main(void)
{
   _CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);
   TestMemLeakage_uv_loop();
}

调试窗格中的输出：

Detected memory leaks!
Dumping objects ->
{96} normal block at 0x0095B718, 32 bytes long.
 Data: <                > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Object dump complete.

不是大漏，但它是！请测试一下。我应该创建错误报告吗？

更新。此泄漏不依赖于循环次数。（我没有仔细测试，也没有深入测试）。下一个代码导致相同的内存泄漏：

void main(void)
{
   _CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);
   for(int i=0; i<100; ++i)
       TestMemLeakage_uv_loop();
}

Upd2。以下是TestMemLeakage_uv_loop()之前和之后的2个群集快照的比较。 http://image.prntscr.com/image/a42cf8945eaa4cb58a94eaea1e7c099e.png 已经进行了180次分配而未取消分配，其中1次由printf制作我不明白这是不是正常情况。

Answer 1

您可以追踪分配的位置吗？ libuv可能会分配一些永远不会被释放的全局结构（IIRC与线程池相关的东西）。

在Unix上我们使用析构函数，但是你的泄漏检测器也会捕获它们，因为它们会在主要返回后运行。

Answer 2

由于这32个字节的泄漏不会随着时间的推移而增长，并且不会增加连接数，循环数，句柄数等。我总结不严重并让它成为。： - ）< / p>

libuv在最简单的例子中有内存泄漏吗？

2 个答案: