Re: Lua assertion during garbage collection when using a weak table

[Roberto Ierusalimschy <roberto@...>]

Sorry to come that late to this problem. Many thanks for the detailed
analysis.


> I _think_ the assertion is invalid and that there's no real problem.
> (But I'm not completely sure.)

I guess you are right. After that assertion, 'atomic' does a
'propagateall' itself, which will add objects to those lists.
Nothing between the assertion and this first 'propagateall'
are affected by those lists. Probably, that assertion could
come before that previous 'propagateall', or that 'propagateall'
could be removed.


> This is my reading of the code:
> 
> [...]
> 
> So the question is, can a weak table be added to the gray list in this
> time window? That can happen if the table is marked via one of the
> barrier functions, and it looks like luaC_upvalbarrier is the likely
> candidate: when the returned anonymous function is closed over
> "weaktable", the value (the weak table) is marked and becomes gray.

A key point here is this code in 'traverseweak' (and similarly
in 'traverseephemeron'):

  if (g->gcstate == GCSpropagate)
    linkgclist(h, g->grayagain);  /* must retraverse it in atomic phase */
  else if (hasclears)
    linkgclist(h, g->weak);  /* has to be cleared later */

In the timeframe you mentioned, the GC is already in state GCSatomic,
so table is inserted in the 'g->weak' list.

In 5.4, this test is like this:

  if (g->gcstate == GCSatomic && hasclears)
    linkgclist(h, g->weak);  /* has to be cleared later */
  else
    linkgclist(h, g->grayagain);  /* must retraverse it in atomic phase */

(Note that 5.4 renamed some GC states, so its GCSatomic correspond to
GCSinsideatomic in 5.3.) In that time frame, 5.4 will be in the
state GCSenteratomic, and so the object will not go to the weak
list. However, 'traverseephemeron' still tests against GCSpropagate,
so probably that list has a similar problem.

-- Roberto