[Issue 3454] New: Inconsistent flag setting in GC.realloc()

d-bugmail at puremagic.com d-bugmail at puremagic.com
Thu Oct 29 17:26:45 PDT 2009


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

           Summary: Inconsistent flag setting in GC.realloc()
           Product: D
           Version: 2.035
          Platform: Other
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: druntime
        AssignedTo: sean at invisibleduck.org
        ReportedBy: dsimcha at yahoo.com


--- Comment #0 from David Simcha <dsimcha at yahoo.com> 2009-10-29 17:26:42 PDT ---
GC.realloc() doesn't set the flags on either the old or new memory block for a
whole bunch of code paths.  I was tipped off to this by reading the code while
trying to add precise heap scanning.  Here's a test program that demonstrates
this.

import std.stdio, core.memory;

void main() {
    doTest(1);
    writeln();
    doTest(1024 * 1024);
}

void doTest(size_t multiplier) {
    auto foo = GC.malloc(8 * multiplier);
    auto bar = GC.realloc(foo, 2 * multiplier, GC.BlkAttr.NO_SCAN);

    writeln("Old block attributes:  ", GC.getAttr(foo));
    writeln("New block attributes:  ", GC.getAttr(bar));
    writeln("Old Ptr:  ", foo, "  New Ptr:  ", bar);
}

Output:
Old block attributes:  2
New block attributes:  2
Old Ptr:  961E40  New Ptr:  961E30

Old block attributes:  0
New block attributes:  0
Old Ptr:  10C0000  New Ptr:  10C0000


This is caused by the GC returning early from the B_PAGE path, or if the new
block is almost the same size as the old block.  If I get precise heap scanning
to work, I'll include a fix for this in the patch.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------


More information about the Digitalmars-d-bugs mailing list