search for: leakcheck

...i, On 2020-10-01 15:29:12 -0700, Lang Hames wrote: > 24bytes / object -- Looks like I managed module ownership correctly but > leaked the ThreadSafeModule container. This should be fixed in 5044196b412f. That helped a bit, but not yet fully. Looks like it might be still reachable memory, so leakcheck isn't that helpful. Oooh. I think I see. For various reasons the symbol names we generate are unique over time. But the interned strings aren't cleared ever. Is that right? With massif, I see: -------------------------------------------------------------------------------- n tim...

...gt;> > 24bytes / object -- Looks like I managed module ownership correctly but >> > leaked the ThreadSafeModule container. This should be fixed in >> 5044196b412f. >> >> That helped a bit, but not yet fully. Looks like it might be still >> reachable memory, so leakcheck isn't that helpful. >> >> Oooh. I think I see. For various reasons the symbol names we generate >> are unique over time. But the interned strings aren't cleared ever. Is >> that right? >> >> With massif, I see: >> >> >> -----------------...

Hi, On 2020-09-30 21:31:33 -0700, Lang Hames wrote: > I've taken a first shot at hooking RTDyldObjectLinkingLayer up to the > ResourceTracker API in 7436b2ab2428. Could you let me know whether that > fixes the leak you were seeing? It did improve the situation significantly, thanks! There's still a smaller leak, unfortunately. The function comments for modules say that: /** *