Re: Heap overflow in luaH_get

[Andrew Gierth <andrew@...>]

>>>>> "云风" == 云风 Cloud Wu <cloudwu@gmail.com> writes:

 >> That assert is not reached if the object (in this case the table,
 >> not the metatable) is not white, and in this case it's black. The
 >> metatable, which is in fact freed in that code, is white and
 >> SURVIVAL (not OLD*).

 云风> I see.

 云风> 1. A G_OLD1 table run finalizer in the end of youngcollection() ,
 云风> and moved back to allgc .
 
 云风> 2. Some object contains this table has been resurrected by a
 云风> finalizer.

If you look at the original code, the table being finalized has a
reference captured in an upvalue from within the finalizer.

 云风> 3. In the next youngcollection cycle, the table with G_OLD1 could
 云风> be marked to black by the object contains it.

No, it's already marked black at this point; the cycle that changed it
to OLD1 marks it black in correctgraylists at the end of the cycle.

Had it not been marked black, then marking it via some reference such as
the upvalue that holds it would end up marking the metatable too.

 云风> 4. The table set to G_OLD by `setage(curr,
 云风> nextage[getage(curr)]);` in sweepgen() , and then it is in
 云风> reallyold list .

Currently it never gets this far (at least with ASAN on) because we
crash first.

 云风> So , adding this line in udata2finalize() may fix this bug ?

 云风> static GCObject *udata2finalize (global_State *g) {
 云风>   ...
 云风>   resetbit(o->marked, FINALIZEDBIT);  /* object is "normal" again */
 云风>   setage(o, G_NEW);  /* Treat it as a new object */

Well, there may be other invariants to consider that this might end up
violating.

I follow the "don't propose solutions until the problem is
satisfactorily understood" method of problem solving (this has
considerable experimental support in the field of experimental
psychology). I know it's tempting to post patches as soon as you see a
possible fix, but this is the wrong approach in the long run.

-- 
Andrew.