few notes about the remaining problems with retired buffers

This commit is contained in:
Zahary Karadjov
2013-01-27 22:23:57 +02:00
parent 55f8ed2452
commit 67f37264b3
2 changed files with 8 additions and 2 deletions

View File

@@ -346,6 +346,7 @@ when traceGC:
cfprintf(cstdout, "Allocations: %ld; freed: %ld\n", a, f)
template gcTrace(cell, state: expr): stmt {.immediate.} =
when logGC: writeCell($state, cell)
when traceGC: traceCell(cell, state)
template WithHeapLock(blk: stmt): stmt =
@@ -994,7 +995,7 @@ proc gcMark(gch: var TGcHeap, p: pointer) {.inline.} =
var objStart = cast[PCell](interiorAllocatedPtr(gch.region, cell))
if objStart != nil:
# mark the cell:
if objStart.isBitDown(rcReallyDead):
if objStart.color != rcReallyDead:
if gcDebugging:
# writeCell("marking ", objStart)
else:

View File

@@ -213,7 +213,12 @@ proc setLengthSeq(seq: PGenericSeq, elemSize, newLen: int): PGenericSeq {.
doDecRef(gch.tempStack.d[i], LocalHeap, MaybeCyclic)
gch.tempStack.len = len0
# and set the memory to nil:
# XXX: zeroing out the memory can still result in crashes if a wiped-out
# cell is aliased by another pointer (ie proc paramter or a let variable).
# This is a tought problem, because even if we don't zeroMem here, in the
# presense of user defined destructors, the user will expect the cell to be
# "destroyed" thus creating the same problem. We can destoy the cell in the
# finalizer of the sequence, but this makes destruction non-deterministic.
zeroMem(cast[pointer](cast[TAddress](result) +% GenericSeqSize +%
(newLen*%elemSize)), (result.len-%newLen) *% elemSize)
result.len = newLen