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

[Andrew Gierth <andrew@...>]

>>>>> "Sascha" == Sascha Zelzer <sascha.zelzer@gmail.com> writes:

 Sascha> Could someone tell me if the assertion is pointing to a real
 Sascha> problem, or if its maybe not a valid condition to assert for in
 Sascha> the first place?

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

This is my reading of the code:

The assertion is in the "atomic" function called by singlestep when the
current collection phase is GCSatomic. We get into the atomic phase when
the previous phase, propagation, ran out of objects in g->gray.
Propagation will have left any weak tables on the "grayagain" list;
unless I'm misreading something, it looks like it's intended that
g->weak and g->ephemeron should be empty outside of the atomic phase.

But the atomic step is this:

    case GCSatomic: {
      lu_mem work;
      propagateall(g);  /* make sure gray list is empty */
      work = atomic(L);  /* work is what was traversed by 'atomic' */
      entersweep(L);
      g->GCestimate = gettotalbytes(g);  /* first estimate */;
      return work;
    }

If the gray list had a weak table (of mode "k" or "v", but not "kv")
added to it between the end of the propagation phase and the start of
the atomic step, then propagateall will move that table to either
g->weak or g->ephemeron depending on the weak mode. The following call
to atomic(L) will then hit the assertion.

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.

So I think your program triggers the assertion if it so happens that the
closing of the anonymous function value on exit from f() happens to fall
between the end of a propagate phase of GC and the following atomic
step. This is probably a fairly narrow window to hit, which explains why
the failure is rare.

-- 
Andrew.