tarantool / tarantool / 20591

83%

master: 88%

push

travis-ci

<a href="https://github.com/tarantool/tarantool/commit/d23bb92e7">box: rewrite rollback to savepoint to Lua/C

LuaJIT records traces while interpreting Lua bytecode (considering it&#39;s
hot enough) in order to compile the corresponding execution flow to a
machine code. A Lua/C call aborts trace recording, but an FFI call does
not abort it per se. If code inside an FFI call yields to another fiber
while recording a trace and the new current fiber interpreting a Lua
bytecode too, then unrelated instructions will be recorded to the
current trace.

In short, we should not yield a current fiber inside an FFI call.

There is another problem. Machine code of a compiled trace may sink a
value from a Lua state down to a host register, change it and write back
only at trace exit. So the interpreter state may be outdated during the
compiled trace execution. A Lua/C call aborts a trace and so the code
inside a callee always see an actual interpreter state. An FFI call
however can be turned into a single machine&#39;s CALL instruction in the
compiled code and if the callee accesses a Lua state, then it may see an
irrelevant value.

In short, we should not access a Lua state directly or reenter to the
interpreter from an FFI call.

The box.rollback_to_savepoint() function may yield and another fiber
will be scheduled for execution. If this fiber touches a Lua state, then
it may see an inconsistent state and the behaviour will be undefined.

Noted that &lt;struct txn&gt;.id starts from 1, because we lean on this fact
to use luaL_toint64(), which does not distinguish an unexpected Lua type
and cdata&lt;int64_t&gt; with zero value. It seems that this assumption
already exists: the code that prepare arguments for &#39;on_commit&#39; triggers
uses luaL_toint64() too (see lbox_txn_pairs()).

Fixes #4427

Co-authored-by: Alexander Turenko &lt;alexander.turenko@tarantool.org&gt;
Reviewed-by: Igor Munkin &lt;imun@tarantool.org&gt;
(cherry pic... (continued)

35 of 35 new or added lines in 1 file covered. (100.0%)

41799 of 50666 relevant lines covered (82.5%)

882343.17 hits per line