Debugging memory leak.

Frits van Bommel fvbommel at REMwOVExCAPSs.nl
Mon Oct 8 09:40:33 PDT 2007


Sean Kelly wrote:
> David Brown wrote:
>>
>> Ideas for possibly fixing this:
>>
>>   - Manually 'delete' these buffers.  In my instance, this wouldn't 
>> really
>>     be all that difficult since I know when they go out of use.
>>
>>   - Call std.gc.hasNoPointers(void*) on the block.  I would think this is
>>     the case for a char[], but std.zlib.compress uses a void[], which the
>>     compiler can't make this assumption about.
> 
> std.zlib should likely be changed to use a byte[] array instead.

Yes it should. I created a quick patch for the gphobos version of 
std.zlib (since the OP was using GDC). I attached it to this post (not 
pasted inline due to line wrapping issues).
I haven't tested it other than running it through 'gdc -c', but it's 
such a trivial patch that the fact it compiles should mean it should 
function identically (except for not allocating void[]s, and thus 
hopefully prevent some memory leakage).

>>   - 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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zlib.diff
Type: text/x-patch
Size: 2920 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20071008/8d035702/attachment.bin>


More information about the Digitalmars-d mailing list