Problems with GC, trees and array concatenation
Oskar Linde
oskar.lindeREM at OVEgmail.com
Mon Jun 4 08:11:27 PDT 2007
Frits van Bommel skrev:
> Babele Dunnit wrote:
>> Seems to me that DEFINITELY there is something in array concatenation
>> code which fools the GC - the Windows version of it, I mean...
>
> Looking at the GC code I can't seem to find any place where arr[length
> .. _gc.cap(arr)] (the unused part of the array allocation) is
> initialized. This could explain the issue if your arrays have different
> lengths (since the data from an longer old array may be present after a
> shorter new array, and is considered as "live" pointers by the GC
> because it's within the same allocation block).
The code that clears arr[length.._gc.cap(arr)] lies in gcx.d. Search for
the phrase "inline"
The code is actually commented out on DMD:
//foreach(inout byte b; cast(byte[])(p + size)[0..binsize[bin] - size])
{ b = 0; }
A patch that reverses that comment:
--- gcx.d 2007-06-04 16:47:02.354590379 +0200
+++ gcx.d.new 2007-06-04 16:46:53.331933006 +0200
@@ -297,7 +297,7 @@
gcx.bucket[bin] = (cast(List *)p).next;
//memset(p + size, 0, binsize[bin] - size);
// 'inline' memset - Dave Fladebo.
- //foreach(inout byte b; cast(byte[])(p +
size)[0..binsize[bin] - size]) { b = 0; }
+ foreach(inout byte b; cast(byte[])(p +
size)[0..binsize[bin] - size]) { b = 0; }
//debug(PRINTF) printf("\tmalloc => %x\n", p);
debug (MEMSTOMP) memset(p, 0xF0, size);
}
Actually seems to remove the memory leak on Linux 1.014...
I am unable to test this on windows.
Note that on GDC, the above code is replaced by a memset(...,0,...) that
is run conditional to a version(GNU), so that may be the reason the leak
doesn't exist on OSX.
/Oskar
More information about the Digitalmars-d
mailing list