www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - Possible bug in GC code

reply Sean Kelly <sean f4.ca> writes:
From my reading of the GC code, mark (in gcx.d) seems like it's intended to scan
all addresses from p1 to p2, inclusive.  But it will never scan p2, as the for
loop does a traditional less-than comparison (so only the range [p1..p2) is
scanned).  Am I currect in assuming this is a bug?  If so, the comparison should
be changed to less-equal and a check for pbot|ptop == null should be added
before the loop (as mark is called with null pointers occasionally).


Sean
Sep 15 2005
parent reply Sean Kelly <sean f4.ca> writes:
In article <dgcpf0$25lu$1 digitaldaemon.com>, Sean Kelly says...
From my reading of the GC code, mark (in gcx.d) seems like it's intended to scan
all addresses from p1 to p2, inclusive.  But it will never scan p2, as the for
loop does a traditional less-than comparison (so only the range [p1..p2) is
scanned).  Am I currect in assuming this is a bug?

It looks like other parts of the GC code expect ptop to point beyond the scannable range as well, so perhaps I'm wrong (the variable name led me to believe that it pointed to a valid memory location). However, if this is true, the use of the CONTEXT structure might be off by one. Assuming, that is, that the stack base or Eip might point to GCed memory (not likely, though I don't quite understand why Ebp is scanned either so who knows). I just want to sort out how mark is intended to be called either way. Sean
Sep 15 2005
parent Sean Kelly <sean f4.ca> writes:
In article <dgcr1j$272r$1 digitaldaemon.com>, Sean Kelly says...
In article <dgcpf0$25lu$1 digitaldaemon.com>, Sean Kelly says...
From my reading of the GC code, mark (in gcx.d) seems like it's intended to scan
all addresses from p1 to p2, inclusive.  But it will never scan p2, as the for
loop does a traditional less-than comparison (so only the range [p1..p2) is
scanned).  Am I currect in assuming this is a bug?

It looks like other parts of the GC code expect ptop to point beyond the scannable range as well, so perhaps I'm wrong (the variable name led me to believe that it pointed to a valid memory location). However, if this is true, the use of the CONTEXT structure might be off by one. Assuming, that is, that the stack base or Eip might point to GCed memory (not likely, though I don't quite understand why Ebp is scanned either so who knows). I just want to sort out how mark is intended to be called either way.

A final follow-up. It looks like mark is being called correctly. I was thrown off because ptop refers to a valid allocated memory address (so far as I can tell) but it will never be allocated to. The code that scans registers might be a tad off, but the missed addresses are either covered by the other scan (scack vs. register or vice-versa) or they simply don't matter (the stack bottom). Sean
Sep 16 2005