http://d.puremagic.com/issues/show_bug.cgi?id=11435
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #1 from [email protected] 2013-11-04 13:30:29 PST --- 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. Relevent issue: http://d.puremagic.com/issues/show_bug.cgi?id=10589 (also related) http://d.puremagic.com/issues/show_bug.cgi?id=9092 That said, "nobug1" is (afaik) the only block that does any manual memory management, so I don't think the issue comes from that (but I think it is worth mentioning). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
