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