http://d.puremagic.com/issues/show_bug.cgi?id=11435
--- Comment #2 from safety0ff.bugz <[email protected]> 2013-11-04 13:38:51 PST --- (In reply to comment #1) > Very very nice. > > Have you been unable to reproduce locally, or do you just have no access to 32 > bit machines? I had tried to reproduce locally before, but failed. I'll try > again with your reduced code though. > > I couldn't help noticing this line though (and am surprised it is actually in > a > nobug1 block): > ptr = cast(size_t*)GC.realloc(ptr, newdim*size_t.sizeof, GC.BlkAttr.NO_SCAN | > GC.BlkAttr.APPENDABLE); > > This is *wrong*. Really, the mode "APPENDABLE" really shouldn't even be > publicly documented. The problem is that (re)alloc (and friends) will return > the "raw" memory block, including the parts reserved to define the block's > currently used length, regardless of the blocks' attributes. This leads to the > inevitable clobbering of said appendable data. That flag did not seem to affect the behaviour. Maybe I should remove it so it does not become a distraction. I do not have any 32 bit dev machines set up. It did fail on the linux 64/32 auto-tester, but generating 32 bit code locally did not fail on my 64bit machine. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
