Re: Conservative GC isn't safe

[Stefan Monnier]

>> Yes, basically, that kind of manipulation.
> All of these cases are in intervals.c.
> There are no other calls to make_interval anywhere in our sources.
> So the question is: are those _the_only_ cases that you are talking
> about, or do you see any others?

I think the only code that manipulates struct intervals is in
intervals.c, indeed, and the risks should be limited to this file.

>> IOW it sounds difficult to make such a test be "complete" (catch
>> most/all cases).
> That doesn't mean we shouldn't do what we can.
> Provided that we consider this danger to be real, of course.

Right, it's a tradeoff.  I personally don't think the tradeoffs favor
writing such code (which is why I haven't done any such thing), as
opposed to relying on code review (this code doesn't change very often).

>> I also think it could prove fiddly to avoid false positives.
> How can this cause false positives?

I was mostly thinking of cases where the flag that signals we're
in the process of manipulating intervals could stay set after the fact
(because of non-local exit), but I'm sure there could be other cases
(it will all depend on exactly what we check and how): false positives
are pretty hard to avoid completely.

> The current code doesn't allow any GC in those functions I described
> above.  This is purely a defensive technique against possible changes
> in the future which will mistakenly allow that.

Another approach would be to change the conservative GC code so as to
also look for "struct intervals" pointers.  We could do it "all the
time", so as to just completely avoid the problem, or we could do it
only depending on a debug flag and then signal an error when this extra
code detects a reference that's not "redundant".

In any case, so far I think it's just a problem in theory, but in
practice I haven't seen any indication that we really have a problem.


        Stefan