Closed aferust closed 2 years ago
Hi @aferust thanks for the report! (edit: reproduced (edit2: no))
I don't think Map this is the leak you are searching.
clearContents()
does not deallocate _rbt
itself. If you close the scope and measure allocations everything is returned.
Map is lazy-initialized so that Map.init is a valid Map, but an empty Map is still one allocation.
import dplug.core;
int main() @nogc nothrow
{
import core.stdc.stdio;
{
Map!(int, int) aa0;
foreach (i; 0..1000){
aa0[i] = i;
}
foreach (i; 0..1000){
printf("%d \n", i);
aa0.remove(i);
}
aa0.clearContents();
} // aa0 destroyed here. After this scope, number of destroyFree and mallocNew is matched
return 0;
}
I am creating a betterC port of the RedBlackTree and Map. I used struct for RBtree instead of class. It looks like I forgot to add an extra destroyFree(_end) for the last node here. Now there is no leak reported with my port. However, drmemory still reports leaks with dplug. I don't know this one is related also.
Well, Inspector report leaks with every D program I've seen. I believe there is something in _Dmain In lack of confirmed Dplug bug, I would prefer to close this as I don't have a reproducible issue?
Interesting. Go close it.
Inspector report leaks with every D program I've seen. I believe there is something in _Dmain
I will keep that in my mind.
It's true small leaks aren't given a high priority in Dplug (vs enterprise software), since a small leak in a plugin instance usually has no impact for the user.
The following D program that prints its arguments:
import std.stdio;
void main(string[] args)
{
foreach(s; args)
writefln("%s", s);
}
has this report in Inspector
When built with LDC instead of DMD:
LDC but with Dr memory: dr-report-ldc.txt
For your example and that example + DMD, DrMemory crash...
so not sure what to do with all those reports. Some of the stack traces are inside MS CRT.
Upon our conversation here, I also installed Inspector. I found out that it is very versatile, easy-to-use, and lightweight. I immediately deleted drmemory from my windows machine forever 😁.
Merci Monsieur.
Yes it is free to use since a few years, you also get Amplifier (though I usually prefer the AMD profiler) :)
The following code causes 40040 bytes of the leak. I mostly used drmemory. But Valgrind yields a similar result too. Maybe, I am wrong but, I somehow detected that while the number of the mallocNew calls for RBNode* is 1001, and the number of the destroyFree calls is 1000 at the end of the scope.