• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

tarantool / tarantool / 20591 / 4
83%
master: 88%

Build:
Build:
LAST BUILD BRANCH: m.kostoev/gh-12564-sigurg-pid-log
DEFAULT BRANCH: master
Ran 05 Feb 2020 06:54PM UTC
Files 306
Run time 58s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

05 Feb 2020 03:46PM UTC coverage: 82.499% (+0.1%) from 82.382%
TARGET=coverage

push

travis-ci

Totktonada
<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)

41799 of 50666 relevant lines covered (82.5%)

882343.17 hits per line

Source Files on job 20591.4 (TARGET=coverage)
  • Tree
  • List 0
  • Changed 254
  • Source Changed 2
  • Coverage Changed 254
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Build 15983
  • Travis Job 20591.4
  • d23bb92e on github
  • Prev Job for TARGET=coverage on 1.10 (#20409.4)
  • Next Job for TARGET=coverage on 1.10 (#20700.4)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc