www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 11435] New: Nondeterministic 32bit release mode access violation

reply d-bugmail puremagic.com writes:
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: -------
Nov 04 2013
next sibling parent d-bugmail puremagic.com writes:
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: -------
Nov 04 2013
prev sibling parent d-bugmail puremagic.com writes:
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: -------
Nov 04 2013