Tarantool development patches archive
 help / color / mirror / Atom feed
* [PATCH] Revert "lua: fix tuple cdata collecting"
@ 2018-12-22 15:33 Vladimir Davydov
  2018-12-22 15:39 ` Vladimir Davydov
  0 siblings, 1 reply; 2+ messages in thread
From: Vladimir Davydov @ 2018-12-22 15:33 UTC (permalink / raw)
  To: tarantool-patches; +Cc: georgy, kyukhin

This reverts commit 022a3c5026fffcecd9bc85f5484d5b5c53ae887d.

According to FFI documentation [1], ffi.cast() creates a new object for
the given type and initializes it with the given value. So setting a
finalizer for a tuple before casting it to const_tuple_ref_t is totally
wrong as it allows the Lua interpreter to invoke the finalizer as soon
as the cast is complete. That said, we must revert the commit that
swapped ffi.cast and ffi.gc order in tuple_bless() and reopen the issue
it intended to fix - see #3751 - no wonder it improved the garbage
collector performance as it basically made all tuples collectable right
from the moment they are blessed.

To make sure we won't step on the same issue again in future, let's also
add a relevant test case.

[1] http://luajit.org/ext_ffi_api.html

Closes #3902
---
 src/box/lua/tuple.lua   |  2 +-
 test/box/tuple.result   | 19 +++++++++++++++++++
 test/box/tuple.test.lua |  9 +++++++++
 3 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/src/box/lua/tuple.lua b/src/box/lua/tuple.lua
index 8662a3a0..63ea73e4 100644
--- a/src/box/lua/tuple.lua
+++ b/src/box/lua/tuple.lua
@@ -100,7 +100,7 @@ local tuple_bless = function(tuple)
     -- overflow checked by tuple_bless() in C
     builtin.box_tuple_ref(tuple)
     -- must never fail:
-    return ffi.cast(const_tuple_ref_t, ffi.gc(tuple, tuple_gc))
+    return ffi.gc(ffi.cast(const_tuple_ref_t, tuple), tuple_gc)
 end
 
 local tuple_check = function(tuple, usage)
diff --git a/test/box/tuple.result b/test/box/tuple.result
index e035cb93..b4201248 100644
--- a/test/box/tuple.result
+++ b/test/box/tuple.result
@@ -1141,6 +1141,25 @@ assert(err ~= nil)
 ---
 - true
 ...
+--
+-- gh-3902: tuple is collected while it's still in use.
+--
+t1 = box.tuple.new(1)
+---
+...
+t1 = t1:update{{'+', 1, 1}}
+---
+...
+collectgarbage()
+---
+- 0
+...
+t2 = box.tuple.new(2)
+---
+...
+t1 = t1:update{{'+', 1, 1}}
+---
+...
 test_run:cmd("clear filter")
 ---
 - true
diff --git a/test/box/tuple.test.lua b/test/box/tuple.test.lua
index 9df978d4..276bb0f6 100644
--- a/test/box/tuple.test.lua
+++ b/test/box/tuple.test.lua
@@ -374,4 +374,13 @@ s:drop()
 _, err = s:frommap({ddd = 1, aaa = 2, ccc = 3, bbb = 4})
 assert(err ~= nil)
 
+--
+-- gh-3902: tuple is collected while it's still in use.
+--
+t1 = box.tuple.new(1)
+t1 = t1:update{{'+', 1, 1}}
+collectgarbage()
+t2 = box.tuple.new(2)
+t1 = t1:update{{'+', 1, 1}}
+
 test_run:cmd("clear filter")
-- 
2.11.0

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2018-12-22 15:39 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-12-22 15:33 [PATCH] Revert "lua: fix tuple cdata collecting" Vladimir Davydov
2018-12-22 15:39 ` Vladimir Davydov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox