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


--- Comment #0 from safety0ff.bugz <safety0ff.bugz@gmail.com> 2013-11-04 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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=11435


monarchdodra@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |monarchdodra@gmail.com


--- Comment #1 from monarchdodra@gmail.com 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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=11435



--- Comment #2 from safety0ff.bugz <safety0ff.bugz@gmail.com> 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: -------