From: Cyrill Gorcunov <gorcunov@gmail.com> To: tml <tarantool-patches@freelists.org> Cc: Alexander Turenko <alexander.turenko@tarantool.org>, Kirill Yukhin <kyukhin@tarantool.org> Subject: [tarantool-patches] [PATCH 2/3] Fix rechaining of pseudo-resurrected string keys. Date: Sat, 18 May 2019 15:33:55 +0300 [thread overview] Message-ID: <20190518123356.15780-3-gorcunov@gmail.com> (raw) In-Reply-To: <20190518123356.15780-1-gorcunov@gmail.com> From: Mike Pall <mike> 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. backport https://github.com/openresty/luajit2/commit/046129dbdda5261c1b17469a2895a113d14c070a Part-of #4171 --- src/lj_tab.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/src/lj_tab.c b/src/lj_tab.c index 47c0cfd..c51666d 100644 --- a/src/lj_tab.c +++ b/src/lj_tab.c @@ -491,6 +491,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; } -- 2.20.1
next prev parent reply other threads:[~2019-05-18 12:35 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-18 12:33 [tarantool-patches] [PATCH 0/3] luajit: Fixes in sake of #4171 Cyrill Gorcunov 2019-05-18 12:33 ` [tarantool-patches] [PATCH 1/3] Fix overflow of snapshot map offset Cyrill Gorcunov 2019-05-18 12:33 ` Cyrill Gorcunov [this message] 2019-05-18 12:38 ` [tarantool-patches] [PATCH 3/3] bugfix: LuaJIT tables' hash chains might get corrupted leading to infinite loops while fetching, missing keys, and etc Cyrill Gorcunov 2019-05-19 18:13 ` [tarantool-patches] Re: [PATCH 0/3] luajit: Fixes in sake of #4171 Alexander Turenko 2019-05-19 18:23 ` Cyrill Gorcunov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190518123356.15780-3-gorcunov@gmail.com \ --to=gorcunov@gmail.com \ --cc=alexander.turenko@tarantool.org \ --cc=kyukhin@tarantool.org \ --cc=tarantool-patches@freelists.org \ --subject='Re: [tarantool-patches] [PATCH 2/3] Fix rechaining of pseudo-resurrected string keys.' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox