> On 6 Nov 2015, at 13:32, Mark H Weaver <m...@netris.org> wrote:
>> We should fix Guile so to "null out" the SMOB typecode when the SMOB >> finalizer is called. If our mark procedure sees a SMOB that has already >> been finalized, it just returns. > > Unfortunately, I doubt this will be sufficient for LilyPond. The small > example case in <http://bugs.gnu.org/19883>, which is apparently > representative of how things are typically done in LilyPond, has > structures like this: > > __________ __________ > Objects in | | | | > GC-managed | SMOB 1 | | SMOB 2 | > heap |__________| |__________| > | ^ | ^ > .....................|...|.........................|...|.......... > __v___|___ _________ __v___|___ > Objects in | | | STL | | | > normal heap |C++ object|--->|container|-->|C++ object| > (not scanned |__________| |_________| |__________| > by GC) > > > The SMOB finalizers free the associated C++ objects below them. Now, > suppose that none of the objects above are reachable, so both SMOBs are > queued for finalization. Now suppose that SMOB 2 is finalized first, > thus freeing the C++ object below it. Suppose further that we null out > the SMOB 2 typecode. > > Now another GC occurs and the marker is called on SMOB 1. It's typecode > has not yet been nulled, so the user-specified mark procedure is called. > The mark procedure for SMOB 1 iterates over the STL container, and for > each C++ object within, marks the corresponding SMOB via the upward > pointer, in this case SMOB 2. Although SMOB 2's typecode has been > zeroed out, the discovery of the fact is too late, because the (freed) > C++ object below it has been referenced. > > As far as I can tell, this way of doing things depends on the old 1.8 GC > finalization semantics, where all of the finalizers are called before > the mutator resumes execution. Is Guile 2 doing its own finalization, not synced withe the Boehm GC?
