506644 - RCObjects allocated during ZCT reaping may incorrectly be deleted under complicated circumstances

Status: RESOLVED WONTFIX

(Tamarin Graveyard :: Garbage Collection (mmGC), defect)

Description

[Lars T Hansen]

Complicated scenario: a C++ finalizer for an object that is deleted by the reaper allocates a new RCObject.  Because this object is new it is entered into the ZCT (its RC is 0).  Suppose the finalizer stores a pointer to this object into some stack variable in a frame older than that of the reaper's; for example, it can do this by grabbing a pointer from a global or thread-local variable that points into the stack and store through that.  Now the new object is referenced from the stack and should not be deleted.  Yet the new object is not pinned, because it didn't exist when we ran pinning, so it may be deleted by the reaper anyway.

On the one hand this is a "don't do that, then" bug.

On the other hand there's the fact that we already have special cases in the allocator for when gc->collecting is true, and that this case is really analogous to that: special considerations apply for allocations during reclamation, and this is just one more special consideration.

(I have not seen this to be a problem in live code, it's just a consequence of the code as it's written.)

Comment 1

[Lars T Hansen]

The same problem applies to non-stack roots, that is, global locations and notably the mark stack and the barrier stack.  (That is, objects on the mark stack were reachable at some point, but the references that put them there may since have been cleared out, and their reference counts may therefore be zero.)  I've run into this in practice now with an object on the write barrier stack being deleted by the reaper - chaos ensues.

Comment 2

[Sylvestre Ledru [:Sylvestre]]

Tamarin is a dead project now. Mass WONTFIX.

Comment 3

[Sylvestre Ledru [:Sylvestre]]

Tamarin isn't maintained anymore. WONTFIX remaining bugs.