Fix rechaining of pseudo-resurrected string keys.

This is a serious bug. But extremely hard to reproduce, so it went
undetected for 8 years. One needs two resurrections with different
main nodes, which are both in a hash chain which gets relinked on
key insertion where the colliding node is in a non-main position. Phew.

Thanks to lbeiming.
This commit is contained in:
Mike Pall 2018-02-27 23:02:23 +01:00
parent 03cd5aa749
commit 046129dbdd

View File

@ -457,6 +457,29 @@ TValue *lj_tab_newkey(lua_State *L, GCtab *t, cTValue *key)
freenode->next = nn->next;
nn->next = n->next;
setmref(n->next, nn);
/*
** Rechaining a resurrected string key creates a new dilemma:
** Another string key may have originally been resurrected via
** _any_ of the previous nodes as a chain anchor. Including
** a node that had to be moved, which makes them unreachable.
** It's not feasible to check for all previous nodes, so rechain
** any string key that's currently in a non-main positions.
*/
while ((nn = nextnode(freenode))) {
if (tvisstr(&nn->key) && !tvisnil(&nn->val)) {
Node *mn = hashstr(t, strV(&nn->key));
if (mn != freenode) {
freenode->next = nn->next;
nn->next = mn->next;
setmref(mn->next, nn);
} else {
freenode = nn;
}
} else {
freenode = nn;
}
}
break;
} else {
freenode = nn;
}