Reputation: 8201
I took the code snippet from libuv-book https://nikhilm.github.io/uvbook/basics.html and tested it for memory leaks with next simple code:
#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();
}
Output in debug pane:
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.
Not big leakage but it is! Please test it. Should i create bug report?
Update. This leak does not depend on number of loops. (I did not test carefully, and did no go deep) . The next code causes the same memory leakage:
void main(void)
{
_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);
for(int i=0; i<100; ++i)
TestMemLeakage_uv_loop();
}
Upd2. Here are comparison of 2 heap snapshoots before TestMemLeakage_uv_loop()
and after.
180 allocations was made and not deallocated, 1 of them made by
printf
.
I don't understand if this is normal situation.
Upvotes: 0
Views: 541
Reputation: 8201
Since these 32 bytes of leakage do not grow over time, and do not grow over number of connections, loops, handles, etc. I summarize not serious and let it be. :-)
Upvotes: 0
Reputation: 2010
Can you trace where the allocations where made? libuv may allocate some global structures (IIRC something related to the threadpool) which are never deallocated.
On Unix we use destructors, but your leak detector would catch them too, since they'd run after main returns.
Upvotes: 1