http://d.puremagic.com/issues/show_bug.cgi?id=9092
--- Comment #5 from Rainer Schuetze <[email protected]> 2012-12-03 15:07:31 PST --- (In reply to comment #4) > 1. What exactly are inside those 16 bytes? I'd say something along the lines > of > pointer to destructor, and currently used vs capacity? Currently only the number of entries that are actually used in the memory block are stored. This allows to append in place if a slice ends at the end of the used data in the block. It is 16 bytes in case any struct needs that alignment. > 2. Why is this issue *only* showing up when my allocation sizes are exact > multiples of 0x10000 ? The problem happens at page boundaries (4kB), but the "commit" size of GC pools is 64kB, so pages are mapped into memory at that granularity. So you'll probably corrupt memory earlier, but the page fault is likely to happen at 64kB boundaries. > 3. Would it be possible to somehow have extend detect when it is given an > "array allocated pointer"? In that case, it could either refuse to extend, or > assert, or something? I don't think it is GC.extend's job to do this. Although slightly less efficient, I think appender should get the new capacity via capacity(array) instead of calculating it from the return value of GC.extent. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
