Opened 10 years ago

Last modified 7 years ago

#1112 new defect

Figure out a way to safely release objects

Reported by: sjamaan Owned by:
Priority: critical Milestone: someday
Component: core libraries Version: 4.8.x
Keywords: Cc:
Estimated difficulty: hard

Description

The {{release-object}} procedure will just call {{free()}} on the object's pointer. This means that any Scheme variable still referring to the object will now point to free memory, which may get overwritten with arbitrary values.

The GC will not touch memory outside the heap, but it's possible that the freed object's memory gets "pulled in" when resizing the heap upon major GC, which means the GC's tests for whether it's in the heap space will succeed, causing it to treat the object as "valid", even if something else has temporarily written bogus stuff to that memory space in between.

We need a way for the GC to kill all references to the released object, but this is currently impossible: these references are plain pointers, and there is no way to ensure a GC won't find any references to these objects.

The trick used by object-become is to collect these objects on a special stack, and force a major GC, which then treats these objects specially. This is probably too much of performance impact though, because object-evict generally tends to be used for performance reasons.

Perhaps some form of "weak evicted object pointers" can be introduced?

Change History (3)

comment:1 Changed 9 years ago by sjamaan

Milestone: 4.10.04.11.0

comment:2 Changed 9 years ago by sjamaan

Milestone: 4.11.0someday

This is too complicated and it's unrealistic to include it in 4.11 or 5.0, so I'll just relax the timeline to "someday". If anyone disagrees, they're welcome to write a patch for it ;)

comment:3 Changed 7 years ago by sjamaan

Estimated difficulty: hard
Note: See TracTickets for help on using tickets.