digitalmars.D.bugs - [Issue 11435] New: Nondeterministic 32bit release mode access violation
- d-bugmail puremagic.com (32/32) Nov 04 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11435
- d-bugmail puremagic.com (29/29) Nov 04 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11435
- d-bugmail puremagic.com (11/27) Nov 04 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11435
http://d.puremagic.com/issues/show_bug.cgi?id=11435 Summary: Nondeterministic 32bit release mode access violation Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: safety0ff.bugz gmail.com 02:23:49 PST --- Created an attachment (id=1285) Failing code, insert into phobos tree, modified the makefiles, and run the unit test runner The code I'll attach to this bug report is extracted from a phobos pull request, it fails non-deterministically on the 32 bit auto-test machines when running release mode unit tests. I've reduced it as much as I can using the auto-test as it doesn't fail on my personal machine. It fails most consistently on win32 and freebsd 32 machines and has at some point in my testing, failed on all the 32bit auto-test machines. From what I've gathered from debugging, it fails on line 73 in the x.init(v) call, on the 30'th iteration of that second for loop. I've used the following pull request to test and reduce the code, but I am stuck: https://github.com/D-Programming-Language/phobos/pull/1670 In the pull request code, I've included modifications to the code that made the bug disappear. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 04 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11435 monarchdodra gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |monarchdodra gmail.com 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: -------
Nov 04 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11435 13:38:51 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.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: -------
Nov 04 2013