Hello, Olivier Dion <[email protected]> skribis:
> I guess this is internal to how libgc work. From my understanding, and > debugging sessions, the finalized objects is marked when the callback is > called. Thus, the sweep (after the finalizers?) will keep it. I guess > this makes some sens since finalizers can re-introduce "dead" objects. > For obscure reasons, the objects is never finalized again, yet it > should. > > My theory is, after the call to the finalizer, a flag is unset from the > object (done by libgc), thus removing our finalizer that we've just > installed. The object is then simply garbaged collect as usual but we > just don't see it. Would be interesting to track that object with a > watchpoint in GDB to see that in action. OK. >> Do you have tests showing that this patch does indeed fix the problem? > > Nope. I did it manually with your reproducer and I can see the vaccuum > being called and the size of the weakset from %symbols is stable. I > guess we could make a test in C to ensure that our async-gc callback is > indeed called. But I fear spurious failure (rare) due to how > conservative garbage collection works. Yeah, I was asking just in case, but it’s hard or impossible to have definite black-box tests for that. > Same. But TBH, I think this gets fixed by Whippet so I don't think we > need the fix that badly. It would be nice however to have it for Guile > 3 if we don't bump to Guile 4 with Whippet. Yes, but if it does improve things, it’s worth having on Guile 3. It’s all about the risk/benefit ratio! Thanks, Ludo’.
