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