Hacker News Reader

Comment by zozbot234 | Hacker News Reader

Doesn't Fil-C use a garbage collector to address use-after-free? For a real use-after-free to be possible there must be some valid pointer to the freed allocation, in which case the GC just keeps it around and there's no overt crash.

View on HN

Yes, Fil-C uses some kind of garbage collector. But it can still detect use-after-free: In the 'free' call, the object is marked as free. In the garbage collection (in the mark phase), if a reference is detected to an object that was freed, then the program panics. Sure, it is also possible to simply ignore the 'free' call - in which case you "just" have a memory leak. I don't think that's what Fil-C does by default however. (This would be more like the behavior of the Boehm GC library for C, if I understand correctly.)

I don’t think that’s how it works. Once an object is freed, any access will crash. You’re allowed to still have a reference to it.

Ok, you are right. My point is, yes it is possible to panic on use-after-free with Fil-C. With Fil-C, a life reference to a freed object can be detected.

A free()-d object that is NOT garbage-collected during the next collection is a bug in itself.

The Fil-C GC will only GC a free'd object if it succeeds at repointing all capabilities to it to point at the free singleton instead.

Don't worry, it's totally sound.

I'm not sure what you mean. Do you mean there is a bug _in the garbage collection algorithm_, if the object is not freed in the very next garbage collection cycle? Well, it depends: the garbage collection could defers collection of some objects until memory is low. Multi-generation garbage collection algorithm often do this.

You can defer the actual freeing of the object until at least one GC pass finishes. Then alert if any of them are still reachable.

Reply on news.ycombinator.com