New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
box-tap/key_def.test.lua flaky fails #4252
Comments
It reproduces with good probability after the following patch: diff --git a/test/box-tap/key_def.test.lua b/test/box-tap/key_def.test.lua
index 4b468a696..2c1e3afda 100755
--- a/test/box-tap/key_def.test.lua
+++ b/test/box-tap/key_def.test.lua
@@ -440,9 +440,13 @@ test:test('merge()', function(test)
test:is_deeply(key_def_ab:extract_key(tuple_a):totable(), {1, 1, 22},
'case 1: verify with :extract_key()')
- local key_def_ba = key_def_b:merge(key_def_a)
- local exp_parts = fun.iter(key_def_b:totable())
- :chain(fun.iter(key_def_a:totable())):totable()
+ local key_def_ba
+ local exp_parts
+ for i = 1, 100000 do
+ key_def_ba = key_def_b:merge(key_def_a)
+ exp_parts = fun.iter(key_def_b:totable())
+ :chain(fun.iter(key_def_a:totable())):totable()
+ end
test:is_deeply(key_def_ba:totable(), exp_parts,
'case 2: verify with :totable()')
test:is_deeply(key_def_ba:extract_key(tuple_a):totable(), {1, 22, 1}, But never reproduces when |
@sergos Agreed to look into this issue. |
Here is reproducer: local fun = require('fun')
local function concat(...)
return fun.chain(...):totable()
end
local function x()
for _ = 1, 10000 do
concat({'a', 'b', 'c'}, {'q', 'w', 'e'})
end
end
xpcall(function()
for _ = 1, 100 do
x()
end
end, function(err)
print(debug.traceback(tostring(err)))
os.exit(1)
end) Loops are not necessary. Sometimes it failed with single
Fails for me at Tarantool 1.10.2-1-ge0017ad |
The issue easy reproduced on dev1 host in debian-stretch image with with the following updated script from above: 4252.test:
|
JIT compiler can generate invalid trace for <totable> function breaking its semantics (see LuaJIT/LuaJIT#584). Since interpreter works fine and produces right results, disabling JIT for this function (and all its subfunctions) stops execution failures. Relates to LuaJIT/LuaJIT#584 Fixes #4252 Signed-off-by: Igor Munkin <imun@tarantool.org>
JIT compiler can generate an invalid trace for <fun.chain> iterator (i.e. chain_gen_r1) breaking its semantics (see LuaJIT/LuaJIT#584). Since interpreter works fine and produces the right results, disabling JIT for this function stops execution failures. As a result box-tap/key_def.test.lua is removed from box-tap suite fragile tests list. Relates to LuaJIT/LuaJIT#584 Fixes #4252 Signed-off-by: Igor Munkin <imun@tarantool.org>
JIT compiler can generate an invalid trace for <fun.chain> iterator (i.e. chain_gen_r1) breaking its semantics (see LuaJIT/LuaJIT#584). Since interpreter works fine and produces the right results, disabling JIT for this function stops execution failures. As a result box-tap/key_def.test.lua is removed from box-tap suite fragile tests list. Relates to LuaJIT/LuaJIT#584 Fixes #4252 Reviewed-by: Alexander V. Tikhonov <avtikhon@tarantool.org> Reviewed-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org>
JIT compiler can generate an invalid trace for <fun.chain> iterator (i.e. chain_gen_r1) breaking its semantics (see LuaJIT/LuaJIT#584). Since interpreter works fine and produces the right results, disabling JIT for this function stops execution failures. As a result box-tap/key_def.test.lua is removed from box-tap suite fragile tests list. Relates to LuaJIT/LuaJIT#584 Fixes #4252 Reviewed-by: Alexander V. Tikhonov <avtikhon@tarantool.org> Reviewed-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org> (cherry picked from commit 5fa7ded)
JIT compiler can generate an invalid trace for <fun.chain> iterator (i.e. chain_gen_r1) breaking its semantics (see LuaJIT/LuaJIT#584). Since interpreter works fine and produces the right results, disabling JIT for this function stops execution failures. As a result box-tap/key_def.test.lua is removed from box-tap suite fragile tests list. Relates to LuaJIT/LuaJIT#584 Fixes #4252 Reviewed-by: Alexander V. Tikhonov <avtikhon@tarantool.org> Reviewed-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org> (cherry picked from commit 5fa7ded)
Does it solve only flaky test? Do we need separate ticket for #4252 (comment) ? |
This patch reverts the temporary fix introduced in commit 5fa7ded ("test: disable JIT for Lua Fun chain iterator") since the issues with invalid traces generation for <fun.chain> iterator are resolved and JIT can be enabled back then. Follows up #4252 Follows up #5118 Signed-off-by: Igor Munkin <imun@tarantool.org>
This patch reverts the temporary fix introduced in commit 5fa7ded ("test: disable JIT for Lua Fun chain iterator") since the issues with invalid traces generation for <fun.chain> iterator are resolved and JIT can be enabled back then. Follows up #4252 Follows up #5118 Relates to #5049 Reviewed-by: Alexander Turenko <alexander.turenko@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org>
Reported by Igor Munkin. (cherry picked from commit 33e3f4b) Side exits with the same exitno use the same snapshot for restoring guest stack values. This obliges all guards related to the particular snapshot use the same RegSP mapping for the values to be restored at the trace exit. RENAME emitted prior to the guard for the same snapshot leads to the aforementioned invariant violation. The easy way to save the snapshot consistency is spilling the renamed IR reference, that is done in scope of <asm_snap_checkrename>. However, the previous <asm_snap_checkrename> implementation considers only the IR references explicitly mentioned in the snapshot. E.g. if there is a sunk[1] object to be restored at the trace exit, and the renamed reference is a *STORE to that object, the spill slot is not allocated. As a result an invalid value is stored while unsinking that object at all corresponding side exits prior to the emitted renaming. To handle also those IR references implicitly used in the snapshot, all non-constant and non-sunk references are added to the Bloom filter (it's worth to mention that two hash functions are used to reduce collisions for the cases when the number of IR references emitted between two different snapshots exceeds the filter size). New <asm_snap_checkrename> implementation tests whether the renamed IR reference is in the filter and forces a spill slot for it as a result. [1]: http://wiki.luajit.org/Allocation-Sinking-Optimization Igor Munkin: * added the description and the test for the problem Resolves tarantool/tarantool#5118 Follows up tarantool/tarantool#4252 Reviewed-by: Sergey Ostanevich <sergos@tarantool.org> Reviewed-by: Sergey Kaplun <skaplun@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org>
This patch reverts the temporary fix introduced in commit 5fa7ded ("test: disable JIT for Lua Fun chain iterator") since the issues with invalid traces generation for <fun.chain> iterator are resolved and JIT can be enabled back then. Follows up #4252 Follows up #5118 Relates to #5049 Reviewed-by: Alexander Turenko <alexander.turenko@tarantool.org> Reviewed-by: Sergey Kaplun <skaplun@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org>
Reported by Igor Munkin. (cherry picked from commit 33e3f4b) Side exits with the same exitno use the same snapshot for restoring guest stack values. This obliges all guards related to the particular snapshot use the same RegSP mapping for the values to be restored at the trace exit. RENAME emitted prior to the guard for the same snapshot leads to the aforementioned invariant violation. The easy way to save the snapshot consistency is spilling the renamed IR reference, that is done in scope of <asm_snap_checkrename>. However, the previous <asm_snap_checkrename> implementation considers only the IR references explicitly mentioned in the snapshot. E.g. if there is a sunk[1] object to be restored at the trace exit, and the renamed reference is a *STORE to that object, the spill slot is not allocated. As a result an invalid value is stored while unsinking that object at all corresponding side exits prior to the emitted renaming. To handle also those IR references implicitly used in the snapshot, all non-constant and non-sunk references are added to the Bloom filter (it's worth to mention that two hash functions are used to reduce collisions for the cases when the number of IR references emitted between two different snapshots exceeds the filter size). New <asm_snap_checkrename> implementation tests whether the renamed IR reference is in the filter and forces a spill slot for it as a result. [1]: http://wiki.luajit.org/Allocation-Sinking-Optimization Igor Munkin: * added the description and the test for the problem Resolves tarantool/tarantool#5118 Follows up tarantool/tarantool#4252 Reviewed-by: Sergey Ostanevich <sergos@tarantool.org> Reviewed-by: Sergey Kaplun <skaplun@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org> (cherry picked from commit 3a2e484)
Reported by Igor Munkin. (cherry picked from commit 33e3f4b) Side exits with the same exitno use the same snapshot for restoring guest stack values. This obliges all guards related to the particular snapshot use the same RegSP mapping for the values to be restored at the trace exit. RENAME emitted prior to the guard for the same snapshot leads to the aforementioned invariant violation. The easy way to save the snapshot consistency is spilling the renamed IR reference, that is done in scope of <asm_snap_checkrename>. However, the previous <asm_snap_checkrename> implementation considers only the IR references explicitly mentioned in the snapshot. E.g. if there is a sunk[1] object to be restored at the trace exit, and the renamed reference is a *STORE to that object, the spill slot is not allocated. As a result an invalid value is stored while unsinking that object at all corresponding side exits prior to the emitted renaming. To handle also those IR references implicitly used in the snapshot, all non-constant and non-sunk references are added to the Bloom filter (it's worth to mention that two hash functions are used to reduce collisions for the cases when the number of IR references emitted between two different snapshots exceeds the filter size). New <asm_snap_checkrename> implementation tests whether the renamed IR reference is in the filter and forces a spill slot for it as a result. [1]: http://wiki.luajit.org/Allocation-Sinking-Optimization Igor Munkin: * added the description and the test for the problem Resolves tarantool/tarantool#5118 Follows up tarantool/tarantool#4252 Reviewed-by: Sergey Ostanevich <sergos@tarantool.org> Reviewed-by: Sergey Kaplun <skaplun@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org> (cherry picked from commit 3a2e484)
Reported by Igor Munkin. (cherry picked from commit 33e3f4b) Side exits with the same exitno use the same snapshot for restoring guest stack values. This obliges all guards related to the particular snapshot use the same RegSP mapping for the values to be restored at the trace exit. RENAME emitted prior to the guard for the same snapshot leads to the aforementioned invariant violation. The easy way to save the snapshot consistency is spilling the renamed IR reference, that is done in scope of <asm_snap_checkrename>. However, the previous <asm_snap_checkrename> implementation considers only the IR references explicitly mentioned in the snapshot. E.g. if there is a sunk[1] object to be restored at the trace exit, and the renamed reference is a *STORE to that object, the spill slot is not allocated. As a result an invalid value is stored while unsinking that object at all corresponding side exits prior to the emitted renaming. To handle also those IR references implicitly used in the snapshot, all non-constant and non-sunk references are added to the Bloom filter (it's worth to mention that two hash functions are used to reduce collisions for the cases when the number of IR references emitted between two different snapshots exceeds the filter size). New <asm_snap_checkrename> implementation tests whether the renamed IR reference is in the filter and forces a spill slot for it as a result. [1]: http://wiki.luajit.org/Allocation-Sinking-Optimization Igor Munkin: * added the description and the test for the problem Resolves tarantool/tarantool#5118 Follows up tarantool/tarantool#4252 Reviewed-by: Sergey Ostanevich <sergos@tarantool.org> Reviewed-by: Sergey Kaplun <skaplun@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org> (cherry picked from commit 3a2e484)
Reported by Igor Munkin. (cherry picked from commit 33e3f4b) Side exits with the same exitno use the same snapshot for restoring guest stack values. This obliges all guards related to the particular snapshot use the same RegSP mapping for the values to be restored at the trace exit. RENAME emitted prior to the guard for the same snapshot leads to the aforementioned invariant violation. The easy way to save the snapshot consistency is spilling the renamed IR reference, that is done in scope of <asm_snap_checkrename>. However, the previous <asm_snap_checkrename> implementation considers only the IR references explicitly mentioned in the snapshot. E.g. if there is a sunk[1] object to be restored at the trace exit, and the renamed reference is a *STORE to that object, the spill slot is not allocated. As a result an invalid value is stored while unsinking that object at all corresponding side exits prior to the emitted renaming. To handle also those IR references implicitly used in the snapshot, all non-constant and non-sunk references are added to the Bloom filter (it's worth to mention that two hash functions are used to reduce collisions for the cases when the number of IR references emitted between two different snapshots exceeds the filter size). New <asm_snap_checkrename> implementation tests whether the renamed IR reference is in the filter and forces a spill slot for it as a result. [1]: http://wiki.luajit.org/Allocation-Sinking-Optimization Igor Munkin: * added the description and the test for the problem Resolves tarantool/tarantool#5118 Follows up tarantool/tarantool#4252 Reviewed-by: Sergey Ostanevich <sergos@tarantool.org> Reviewed-by: Sergey Kaplun <skaplun@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org>
This patch reverts the temporary fix introduced in commit 5fa7ded ("test: disable JIT for Lua Fun chain iterator") since the issues with invalid traces generation for <fun.chain> iterator are resolved and JIT can be enabled back then. Follows up #4252 Follows up #5118 Relates to #5049 Reviewed-by: Alexander Turenko <alexander.turenko@tarantool.org> Reviewed-by: Sergey Kaplun <skaplun@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org> (cherry picked from commit 20c0a12)
This patch reverts the temporary fix introduced in commit 5fa7ded ("test: disable JIT for Lua Fun chain iterator") since the issues with invalid traces generation for <fun.chain> iterator are resolved and JIT can be enabled back then. Follows up #4252 Follows up #5118 Relates to #5049 Reviewed-by: Alexander Turenko <alexander.turenko@tarantool.org> Reviewed-by: Sergey Kaplun <skaplun@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org> (cherry picked from commit 20c0a12)
This patch reverts the temporary fix introduced in commit 5fa7ded ("test: disable JIT for Lua Fun chain iterator") since the issues with invalid traces generation for <fun.chain> iterator are resolved and JIT can be enabled back then. Follows up #4252 Follows up #5118 Relates to #5049 Reviewed-by: Alexander Turenko <alexander.turenko@tarantool.org> Reviewed-by: Sergey Kaplun <skaplun@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org> (cherry picked from commit 20c0a12)
This patch reverts the temporary fix introduced in commit 5fa7ded ("test: disable JIT for Lua Fun chain iterator") since the issues with invalid traces generation for <fun.chain> iterator are resolved and JIT can be enabled back then. Follows up #4252 Follows up #5118 Relates to #5049 Reviewed-by: Alexander Turenko <alexander.turenko@tarantool.org> Reviewed-by: Sergey Kaplun <skaplun@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org>
This patch reverts the temporary fix introduced in commit 5fa7ded ("test: disable JIT for Lua Fun chain iterator") since the issues with invalid traces generation for <fun.chain> iterator are resolved and JIT can be enabled back then. Follows up #4252 Follows up #5118 Relates to #5049 Reviewed-by: Alexander Turenko <alexander.turenko@tarantool.org> Reviewed-by: Sergey Kaplun <skaplun@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org>
This patch reverts the temporary fix introduced in commit 5fa7ded ("test: disable JIT for Lua Fun chain iterator") since the issues with invalid traces generation for <fun.chain> iterator are resolved and JIT can be enabled back then. Follows up #4252 Follows up #5118 Relates to #5049 Reviewed-by: Alexander Turenko <alexander.turenko@tarantool.org> Reviewed-by: Sergey Kaplun <skaplun@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org>
Reported by Igor Munkin. (cherry picked from commit 33e3f4b) Side exits with the same exitno use the same snapshot for restoring guest stack values. This obliges all guards related to the particular snapshot use the same RegSP mapping for the values to be restored at the trace exit. RENAME emitted prior to the guard for the same snapshot leads to the aforementioned invariant violation. The easy way to save the snapshot consistency is spilling the renamed IR reference, that is done in scope of <asm_snap_checkrename>. However, the previous <asm_snap_checkrename> implementation considers only the IR references explicitly mentioned in the snapshot. E.g. if there is a sunk[1] object to be restored at the trace exit, and the renamed reference is a *STORE to that object, the spill slot is not allocated. As a result an invalid value is stored while unsinking that object at all corresponding side exits prior to the emitted renaming. To handle also those IR references implicitly used in the snapshot, all non-constant and non-sunk references are added to the Bloom filter (it's worth to mention that two hash functions are used to reduce collisions for the cases when the number of IR references emitted between two different snapshots exceeds the filter size). New <asm_snap_checkrename> implementation tests whether the renamed IR reference is in the filter and forces a spill slot for it as a result. [1]: http://wiki.luajit.org/Allocation-Sinking-Optimization Igor Munkin: * added the description and the test for the problem Resolves tarantool/tarantool#5118 Follows up tarantool/tarantool#4252 Reviewed-by: Sergey Ostanevich <sergos@tarantool.org> Reviewed-by: Sergey Kaplun <skaplun@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org>
Reported by Igor Munkin. (cherry picked from commit 33e3f4b) Side exits with the same exitno use the same snapshot for restoring guest stack values. This obliges all guards related to the particular snapshot use the same RegSP mapping for the values to be restored at the trace exit. RENAME emitted prior to the guard for the same snapshot leads to the aforementioned invariant violation. The easy way to save the snapshot consistency is spilling the renamed IR reference, that is done in scope of <asm_snap_checkrename>. However, the previous <asm_snap_checkrename> implementation considers only the IR references explicitly mentioned in the snapshot. E.g. if there is a sunk[1] object to be restored at the trace exit, and the renamed reference is a *STORE to that object, the spill slot is not allocated. As a result an invalid value is stored while unsinking that object at all corresponding side exits prior to the emitted renaming. To handle also those IR references implicitly used in the snapshot, all non-constant and non-sunk references are added to the Bloom filter (it's worth to mention that two hash functions are used to reduce collisions for the cases when the number of IR references emitted between two different snapshots exceeds the filter size). New <asm_snap_checkrename> implementation tests whether the renamed IR reference is in the filter and forces a spill slot for it as a result. [1]: http://wiki.luajit.org/Allocation-Sinking-Optimization Igor Munkin: * added the description and the test for the problem Resolves tarantool/tarantool#5118 Follows up tarantool/tarantool#4252 Reviewed-by: Sergey Ostanevich <sergos@tarantool.org> Reviewed-by: Sergey Kaplun <skaplun@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org>
https://travis-ci.org/tarantool/tarantool/jobs/535024408#L3750
I'm able to reproduce it with the following command:
The text was updated successfully, but these errors were encountered: