Debugging memory leak.

[Frits van Bommel]

Sean Kelly wrote:
> Frits van Bommel wrote:
>> Sean Kelly wrote:
>>
>>>>   - Try Tango?  Is the GC different there?
>>>
>>> Somewhat, but void[] arrays are still treated as if they have pointers.
>>
>> But AFAICT tango.io.compress.Zlib doesn't allocate any of those, just 
>> ubyte[] arrays, and exception classes. (The unittest does use a 
>> MemoryConduit, which internally uses a void[], but nothing else should 
>> allocate void[]s for that module)
> 
> Yup.  However, an annoying problem still exists with Buffer.  Basically, 
> this class maintains a void[] reference to a block of memory allocated 
> as a byte[].  However, if the block is resized for any reason, the type 
> doing the resizing is used to determine whether the newly allocated 
> block contains pointers.  I've been meaning to change the Tango runtime 
> and GC to preserve array block attributes across reallocations, but it's 
> a somewhat involved process and I haven't gotten to it yet.

Actually, that bug (or its Phobos equivalent) seems to be partly to 
blame as well. If you look at std.zlib, you'll see that right after 
every "new void[whatever]", std.gc.hasNoPointers is called on the 
result. However, there are some ~/~= operations on those buffers while 
typed as void[]s.
I think if the "has no pointers" bit carried over from the original 
arrays when concatenating (if neither contains pointers[1], the result 
doesn't contain any either) std.zlib might actually be leak-free.


[1]: If an array gc-allocated, use the attribute as set by the 
allocation function or the user. Otherwise, use the default for the 
static type (through TypeInfo).


P.S. I think I'm starting to realize what you meant by that "a somewhat 
involved process" comment ;).