- Dec 11, 2024
-
-
If the write iterator sees that one DELETE statement follows another, which isn't discarded because it's referenced by a read view, it drops the newer DELETE, see commit a6f45d87 ("vinyl: discard tautological DELETEs on compaction"). This is incorrect if the older DELETE is a deferred DELETE statement (marked as SKIP READ) because such statements are dumped out of order, i.e. there may be a statement with the LSN lying between the two DELETEs in an older source not included into this compaction task. If we discarded the newer DELETE, we wouldn't overwrite this statement on major compaction, leaving garbage. Fix this issue by disabling this optimization for deferred DELETEs. Closes #10895 NO_DOC=bug fix (cherry picked from commit 2945a8c9fde6df9f6cbc714f9cf8677f0fded57a)
-
vy_lsm.c seems to be a more appropriate place for cache invalidation because (a) it's vy_lsm that owns the cache and (b) we invalidate the cache on rollback in vy_lsm_rollback_stmt(). While we are at it, let's inline vy_tx_write() and vy_tx_write_prepare() because they are trivial and used in just one place. NO_DOC=refactoring NO_TEST=refactoring NO_CHANGELOG=refactoring (cherry picked from commit 44c245ef0baa227a6bff75de2a91f20da5532dc1)
-
There's no point in doing so because if the committed tuple has been overwritten by the time it's committed, the statement that overwrote it must have already invalidated the cache, see `vy_tx_write()`. The code invalidating the cache on commit was added along with the cache implementation without any justification. NO_DOC=minor NO_TEST=minor NO_CHANGELOG=minor (cherry picked from commit 6ee49a5955893834fdaaf554d57d92d3f35992bc)
-
Once a statement is prepared to be committed to WAL, it becomes visible (in the 'read-committed' isolation level) so it can be added to the tuple cache. That's why if the statement is rolled back due to a WAL error, we have to invalidate the cache. The problem is that the function invalidating the cache (`vy_cache_on_write`) ignores the statement if it's a DELETE judging that "there was nothing and there is nothing now". This is apparently wrong for rollback. Fix it. Closes #10879 NO_DOC=bug fix (cherry picked from commit d64e29da2c323a4b4fcc7cf9fddb0300d5dd081f)
-
A multikey index stores a tuple once per each entry of the indexed array field, excluding duplicates. For example, if the array field equals {1, 3, 2, 3}, the tuple will be stored three times. Currently, when a tuple with duplicate multikey entries is inserted into a transaction write set, duplicates are overwritten as if they belonged to different statements. Actually, this is pointless: we could just as well skip them without trying to add to the write set. Besides, this may break the assumptions taken by various optimizations, resulting in anomalies. Consider the following example: ```lua local s = box.schema.space.create('test', {engine = 'vinyl'}) s:create_index('primary') s:create_index('secondary', {parts = {{'[2][*]', 'unsigned'}}}) s:replace({1, {10, 10}}) s:update({1}, {{'=', 2, {10}}}) ``` It will insert the following entries to the transaction write set of the secondary index: 1. REPLACE {10, 1} [overwritten by no.2] 2. REPLACE {10, 1} [overwritten by no.3] 3. DELETE {10, 1} [turned into no-op as REPLACE + DELETE] 4. DELETE {10, 1} [overwritten by no.5] 5. REPLACE {10, 1} [turned into no-op as DELETE + REPLACE] (1-2 correspond to `replace()` and 3-5 to `delete()`) As a result, tuple {1, {10}} will be lost forever. Let's fix this issue by silently skipping duplicate multikey entries added to a transaction write set. After the fix, the example above will produce the following write set entries: 1. REPLACE{10, 1} [overwritten by no.2] 2. DELETE{10, 1} [turned into no-op as REPLACE + DELETE] 3. REPLACE{10, 1} [committed] (1 corresponds to `replace()` and 2-3 to `delete()`) Closes #10869 Closes #10870 NO_DOC=bug fix (cherry picked from commit 1869dce15d9a797391e45df75507078d91f1651e)
-
A Vinyl read iterator scans all read sources (memory and disk levels) even if it's executed in a read view from which most of the sources are invisible. As a result, a long running scanning request may spend most of the time skipping invisible statements. The situation is exacerbated if the instance is experiencing a heavy write load because it would pile up old statement versions in memory and force the iterator to skip over them after each disk read. Since the replica join procedure in Vinyl uses a read view iterator under the hood, the issue is responsible for a severe performance degradation of the master instance and the overall join procedure slowdown when a new replica is joined to an instance running under a heavy write load. Let's fix this issue by making a read iterator skip read sources that aren't visible from its read view. Closes #10846 NO_DOC=bug fix (cherry picked from commit 6a214e42e707b502022622866d898123a6f177f1)
-
Statements executed in a transaction are first inserted into the transaction write set and only when the transaction is committed, they are applied to the LSM trees that store indexed keys in memory. If the same key is updated more than once in the same transaction, the old version is marked as overwritten in the write set and not applied on commit. Initially, write sets of different indexes of the same space were independent: when a transaction was applied, we didn't have a special check to skip a secondary index statement if the corresponding primary index statement was overwritten because in this case the secondary index statement would have to be overwritten as well. This changed when deferred DELETEs were introduced in commit a6edd455 ("vinyl: eliminate disk read on REPLACE/DELETE"). Because of deferred DELETEs, a REPLACE or DELETE overwriting a REPLACE in the primary index write set wouldn't generate DELETEs that would overwrite the previous key version in write sets of the secondary indexes. If we applied such a statement to the secondary indexes, it'd stay there forever because, since there's no corresponding REPLACE in the primary index, a DELETE wouldn't be generated on primary index compaction. So we added a special instruction to skip a secondary index statement if the corresponding primary index was overwritten, see `vy_tx_prepare()`. Actually, this wasn't completely correct because we skipped not only secondary index REPLACE but also DELETE. Consider the following example: ```lua local s = box.schema.space.create('test', {engine = 'vinyl'}) s:create_index('primary') s:create_index('secondary', {parts = {2, 'unsigned'}}) s:replace{1, 1} box.begin() s:update(1, {{'=', 2, 2}}) s:update(1, {{'=', 2, 3}}) box.commit() ``` UPDATEs don't defer DELETEs because, since they have to query the old value, they can generate DELETEs immediately so here's what we'd have in the transaction write set: 1. REPLACE {1, 2} in 'test.primary' [overwritten by no.4] 2. DELETE {1, 1} from 'test.secondary' 3. REPLACE {1, 2} in 'test.secondary' [overwritten by no.5] 4. REPLACE{1, 3} in 'test.primary' 5. DELETE{1, 2} from 'test.secondary' 6. REPLACE{1, 3} in 'test.secondary' Statement no.2 would be skipped and marked as overwritten because of the new check, resulting in {1, 1} never deleted from the secondary index. Note, the issue affects spaces both with and without enabled deferred DELETEs. This commit fixes this issue by updating the check to only skip REPLACE statements. It should be safe to apply DELETEs in any case. There's another closely related issue that affects only spaces with enabled deferred DELETEs. When we generate deferred DELETEs for secondary index when a transaction is committed (we can do it if we find the previous version in memory), we assume that there can't be a DELETE in a secondary index write set. This isn't true: there can be a DELETE generated by UPDATE or UPSERT. If there's a DELETE, we have nothing to do unless the DELETE was optimized out (marked as no-op). Both issues were found by `vinyl-luatest/select_consistency_test.lua`. Closes #10820 Closes #10822 NO_DOC=bug fix (cherry picked from commit 6a87c45deeb49e4e17ae2cc0eeb105cc9ee0f413)
-
- Nov 22, 2024
-
-
Serge Petrenko authored
Also, remove unreleased/ entries. NO_DOC=changelog NO_TEST=changelog NO_CHANGELOG=changelog
-
- Nov 21, 2024
-
-
Andrey Saranchin authored
Currently, we use raw index for count operation instead of `box_index_count`. As a result, we skip a check if current transaction can continue and we don't begin transaction in engine if needed. So, if count statement is the first in a transaction, it won't be tracked by MVCC since it wasn't notified about the transaction. The commit fixes the mistake. Also, the commit adds a check if count was successful and covers it with a test. In order to backport the commit to 2.11, space name was wrapped with quotes since it is in lower case and addressing such spaces with SQL without quotes is Tarantool 3.0 feature. Another unsupported feature is prohibition of data access in transactional triggers - it was used in a test case so it was rewritten. Closes #10825 NO_DOC=bugfix (cherry picked from commit 0656a9231149663a0f13c4be7466d4776ccb0e66)
-
- Nov 12, 2024
-
-
Vladimir Davydov authored
The test expects at least 10 dumps to be created in 60 seconds. It usually works but sometimes, when the host is heavy loaded, Vinyl doesn't produce enough dumps in time and fails the test. On CI the test usually fails with 7-9 dumps. To avoid flaky failures, let's reduce the expected dump count down to 5. Closes #10752 NO_DOC=test fix NO_CHANGELOG=test fix (cherry picked from commit 5325abd3441ecb4b589799c32ec181d88724b8a8)
-
Vladimir Davydov authored
`vy_mem_insert()` and `vy_mem_insert_upsert()` increment the row count statistic of `vy_mem` only if no statement is replaced, which is correct, while `vy_lsm_commit()` increments the row count of `vy_lsm` unconditionally. As a result, `vy_lsm` may report a non-zero statement count (via `index.stat()` or `index.len()`) after a dump. This may happen only with a non-unique multikey index, when the statement has duplicates in the indexed array, and only if the `deferred_deletes` option is enabled, because otherwise we drop duplicates when we form the transaction write set, see `vy_tx_set()`. With `deferred_deletes`, we may create a `txv` for each multikey entry at the time when we prepare to commit the transaction, see `vy_tx_handle_deferred_delete()`. Another problem is that `vy_mem_rollback_stmt()` always decrements the row count, even if it didn't find the rolled back statement in the tree. As a result, if the transaction with duplicate multikey entries is rolled back on WAL error, we'll decrement the row count of `vy_mem` more times than necessary. To fix this issue, let's make the `vy_mem` methods update the in-memory statistic of `vy_lsm`. This way they should always stay in-sync. Also, we make `vy_mem_rollback_stmt()` skip updating the statistics in case the rolled back statement isn't present in the tree. This issue results in `vinyl-luatest/select_consistency_test.lua` flakiness when checking `index.len()` after compaction. Let's make the test more thorough and also check that `index.len()` equals `index.count()`. Closes #10751 Part of #10752 NO_DOC=bug fix (cherry picked from commit e8810c555d4e6ba56e6c798e04216aa11efb5304)
-
- Nov 07, 2024
-
-
Nikita Zheleztsov authored
This commit fixes some cases of upgrading schema from 1.6.9: 1. Fix updating empty password for users. In 1.6 credentials were array in _user, in 1.7.5 they became map. 2. Automatically update the format of user spaces. Format of system spaces have been properly fixed during upgrade to 1.7.5. However, commit 519bc82e ("Parse and validate space formats") introduced strict checking of format field in 1.7.6. So, the format of user spaces should be also fixed. Back in 1.6 days, it was allowed to write anything in space format. This commit only fixes valid uses of format: {name = 'a', type = 'number'} {'a', type = 'number'} {'a', 'num'} {'a'} Invalid use of format (e.g. {{}}, or {{5, 'number'}} will cause error anyway. User has to fix the format on old version and only after that start a new one. This commit also introduces the test, which checks, that we can properly upgrade from 1.6.9 to the latest versions, at least in basic cases. Closes #10180 NO_DOC=bugfix (cherry picked from commit f69e2ae488b3620e31f1a599d8fb78a66917dbfd)
-
- Nov 01, 2024
-
-
Vladimir Davydov authored
Bump test-run to new version with the following improvements: - Fix a typo [1] - Follow-up fix for parsing non-utf8 chars (part 2) [2] - Bump luatest to 1.0.1-33-g7dc5cb7 [3] [1] tarantool/test-run@5d9630b [2] tarantool/test-run@7acc532 [3] tarantool/test-run@dc2382c NO_DOC=test NO_TEST=test NO_CHANGELOG=test (cherry picked from commit 0afc7e0b8a57678c589a2e9de6785d99f17e30eb)
-
Andrey Saranchin authored
When building an index in background, we create on_rollback triggers for tuples inserted concurrently. The problem here is on_rollback trigger has independent from `index` and `memtx_ddl_state` lifetime - it can be called after the index was build (and `memtx_ddl_state` is destroyed) and even after the index was altered. So, in order to avoid use-after-free in on_rollback trigger, let's drop all on_rollback triggers when the DDL is over. It's OK because all owners of triggers are already prepared, hence, in WAL or replication queue (since we build indexes in background only without MVCC so the transactions cannot yield), so if they are rolled back, the same will happen to the DDL. In order to delete on_rollback triggers, we should collect them into a list in `memtx_ddl_state`. On the other hand, when the DML statement is over (committed or rolled back), we should delete its trigger from the list to prevent use-after-free. That's why the commit adds the on_commit trigger to background build process. Closes #10620 NO_DOC=bugfix (cherry picked from commit d8d82dba4c884c3a7ad825bd3452d35627c7dbf4)
-
Yaroslav Lobankov authored
NO_DOC=test NO_TEST=test NO_CHANGELOG=test (cherry picked from commit 90d197ded13d49dfc405ff80bbd183b2e260dc56)
-
Yaroslav Lobankov authored
Also, adapt tests and helpers in accordance with the module interface. NO_DOC=test NO_TEST=test NO_CHANGELOG=test (cherry picked from commit bd27df009c403e89c003d5b66763c0f0bbf08440)
-
Yaroslav Lobankov authored
Bump test-run to new version with the following improvements: - ignore local lsn in wait_cluster_vclock [1] - Bump luatest to 1.0.1-20-ga978383 [2] - Bump luatest to 1.0.1-22-g39da6d2 [3] [1] tarantool/test-run@f23b535 [2] tarantool/test-run@274e4f3 [3] tarantool/test-run@d04c595 NO_DOC=test NO_TEST=test NO_CHANGELOG=test (cherry picked from commit beba449a5f04e02fb77ca676663b1836e0490c3d)
-
Serge Petrenko authored
Bump test-run to new version with the following improvements: - Follow-up fix for parsing non-utf8 chars [1] [1] tarantool/test-run@52d3e4f NO_CHANGELOG=test NO_TEST=test NO_DOC=test (cherry picked from commit e01c20edc31b65e020ac57e3f62a7427b6e27d53)
-
Serge Petrenko authored
The test gh_10088 was committed in parallel with the luatest bump and thus slipped from the post-bump tests fixup in commit cfd4bf46 ("test: adapt tests to the new luatest version"). Fix it now. Also tests gh_6539 and gh_7231 queried `box.cfg.log` wrongly, but this didn't make them fail, they just stopped testing what they were supposed to. Fix them as well NO_CHANGELOG=test NO_TEST=test NO_DOC=test (cherry picked from commit 2a18de391895d8ec7a39e3d3dcee659fe79f7bc9)
-
Oleg Chaplashkin authored
With the new version of Luatest you have to be careful with the server log file. We used to get it very simply: box.cfg.log Now it is more correct to use the following approach: rawget(_G, 'box_cfg_log_file') or box.cfg.log Closes tarantool/test-run#439 NO_DOC=test NO_TEST=test NO_CHANGELOG=test (cherry picked from commit cfd4bf46)
-
Nikita Zheleztsov authored
Bump test-run to new version with the following improvements: - luatest: fix ability to run a test several times [1] - Enable luatest logging [2] - tap13: fix parsing non-utf8 chars [3] [1] tarantool/test-run@240cdea [2] tarantool/test-run@b8b60b4 [3] tarantool/test-run@7290540 NO_DOC=test NO_TEST=test NO_CHANGELOG=test (cherry picked from commit 59ba2131)
-
- Oct 31, 2024
-
-
Andrey Saranchin authored
The commit bumps luafun to the new version with a bunch of bugfixes: * Now `chain` works correctly with iterators without `param`. * Now `drop_while` supports stateful iterators. * The module is populated with missing `maximum_by` alias of `max_by`. * Now `nth` and `length` work correctly with other luafun iterators. Since our index iterators are stateful (can return different values with the same `state` passed), the old `drop_while` implementation didn't work well with them - it was skipping an extra element. The bump resolves this issue. Note that there are still methods that don't work correctly with `index:pairs` - `cycle`, `head` and `is_null`. Closes #6403 NO_DOC=bugfix (cherry picked from commit ec758869f8364624efaff58bdd4ebc7c133ede0a)
-
- Oct 30, 2024
-
-
Sergey Bronnikov authored
GNU GCC compiler has UndefinedBehaviour sanitizer support since 4.9.0 [1], but it was unsupported in tarantool's build. The patch fixes a build by GNU GCC with enabled UBSan. 1. https://gcc.gnu.org/gcc-4.9/changes.html NO_CHANGELOG=build NO_DOC=build NO_TEST=build (cherry picked from commit 511e0f50e4b817d576ef4001611fba718ef1bdae)
-
Sergey Bronnikov authored
The patch enable UBsan check signed-integer-overflow that was disabled globally in commit 5115d9f3 ("cmake: split UB sanitations into separate flags.") and disable it for a several functions inline. See also #10703 See also #10704 Closes #10228 NO_CHANGELOG=codehealth NO_DOC=codehealth NO_TEST=codehealth (cherry picked from commit 60ba7fb4c0038d9d17387f7ce9755eb587ea1da4)
-
Sergey Bronnikov authored
The following UBSan checks have been enabled back: - vptr - implicit-signed-integer-truncation - implicit-integer-sign-change - nullability-arg - nullability-assign - nullability-return - returns-nonnull-attribute These checks doesn't trigger errors anymore and no sense to keep them disabled. Part of #10228 Related to #10741 Related to #10740 NO_CHANGELOG=codehealth NO_DOC=codehealth NO_TEST=codehealth (cherry picked from commit e65b63df7f5a8a628cd9a9bbc6a1bdecec8c9959)
-
Sergey Bronnikov authored
The commit 366cb668 ("cmake: add option ENABLE_UB_SANITIZER") added UndefinedBehaviour sanitizer support with the whitelist of checks (all checks are disabled and a several checks are enabled). The patch replaces the whitelist by blacklist (all checks are enabled and a several checks are disabled). Part of #10228 Related to #10742 NO_CHANGELOG=codehealth NO_DOC=codehealth NO_TEST=codehealth (cherry picked from commit 2125a4304844669884bfa887657fd20f15504a5a)
-
- Oct 28, 2024
-
-
Andrey Saranchin authored
Currently, we create `memtx_tx_snapshot_cleaner` for each index in read view. However, we somewhy clarify all tuples against primary index in all cleaners. As a result, secondary indexes work incorrectly in read view when MVCC is enabled, we may even get a tuple with one key, but a tuple with another key will be returned because it is clarified against primary index and repsects its order - that's wrong because all indexes have its own orders. Let's clarify tuples against given index to fix this mistake. Community Edition is not affected at all since it uses read view only for making a snapshot - we use only primary indexes there. Part of tarantool/tarantool-ee#939 NO_TEST=in EE NO_CHANGELOG=in EE NO_DOC=bugfix (cherry picked from commit 835fadd)
-
- Oct 23, 2024
-
-
Nikolay Shirokovskiy authored
I got compile error for release build on gcc 14.2.1 20240910 version. ``` In function ‘char* mp_store_double(char*, double)’, inlined from ‘char* mp_encode_double(char*, double)’ at /home/shiny/dev/tarantool-ee/tarantool/src/lib/msgpuck/msgpuck.h:2409:24, inlined from ‘uint32_t tuple_hash_field(uint32_t*, uint32_t*, const char**, field_type, coll*)’ at /home/shiny/dev/tarantool-ee/tarantool/src/box/tuple_hash.cc:317:46: /home/shiny/dev/tarantool-ee/tarantool/src/lib/msgpuck/msgpuck.h:340:16: error: ‘value’ may be used uninitialized [-Werror=maybe-uninitialized] 340 | cast.d = val; | ~~~~~~~^~~~~ /home/shiny/dev/tarantool-ee/tarantool/src/box/tuple_hash.cc: In function ‘uint32_t tuple_hash_field(uint32_t*, uint32_t*, const char**, field_type, coll*)’: /home/shiny/dev/tarantool-ee/tarantool/src/box/tuple_hash.cc:311:24: note: ‘value’ was declared here 311 | double value; | ``` NO_TEST=build fix NO_CHANGELOG=build fix NO_DOC=build fix (cherry picked from commit 1129c758d0e3bd86eec89e5229eac3f99155d8ac)
-
- Oct 18, 2024
-
-
Sergey Kaplun authored
* Fix typo. * OSX/iOS: Always generate 64 bit non-FAT Mach-O object files. * test: don't run JIT-based LuaJIT tests without JIT * test: actualize <LuaJIT-tests/README.md> * test: enable <misc/alias_alloc.lua> LuaJIT test * test: refactor <alias_alloc.lua> LuaJIT test * test: refactor <lang/coroutine.lua> LuaJIT test * test: remove <misc/coro_yield.lua> LuaJIT test * test: enable <misc/debug_gc.lua> LuaJIT test * test: enable <misc/dualnum.lua> LuaJIT test * test: refactor <lang/dualnum.lua> LuaJIT test * test: remove <misc/fori_coerce.lua> LuaJIT test * test: remove <misc/fori_dir.lua> LuaJIT test * test: remove <misc/gc_rechain.lua> LuaJIT test * test: enable <misc/gc_trace.lua> LuaJIT test * test: refactor <trace/gc.lua> LuaJIT test * test: enable <misc/gcstep.lua> LuaJIT test * test: enable <misc/hook_active.lua> LuaJIT test * test: enable <misc/hook_line.lua> LuaJIT test * test: enable <misc/hook_norecord.lua> LuaJIT test * test: enable <misc/hook_record.lua> LuaJIT test * test: enable <misc/hook_top.lua> LuaJIT test * test: enable <misc/jit_flush.lua> LuaJIT test * test: remove <misc/loop_unroll.lua> LuaJIT test * test: enable <misc/parse_comp.lua> LuaJIT test * test: enable <misc/parse_esc.lua> LuaJIT test * test: enable <misc/parse_misc.lua> LuaJIT test * test: enable <misc/phi_conv.lua> LuaJIT test * test: refactor <trace/phi/conv.lua> LuaJIT test * test: enable <misc/recurse_deep.lua> LuaJIT test * test: remove <misc/recurse_tail.lua> LuaJIT test * test: enable <misc/stack_gc.lua> LuaJIT test * test: refactor <lang/gc_stack.lua> LuaJIT test * test: enable <misc/stack_purge.lua> LuaJIT test * test: refactor <trace/stack_purge.lua> LuaJIT test * test: enable <misc/stackov.lua> LuaJIT test * test: enable <misc/stackovc.lua> LuaJIT test * test: enable <misc/tcall_base.lua> LuaJIT test * test: refactor <trace/tcall_base.lua> LuaJIT test * test: enable <misc/tcall_loop.lua> LuaJIT test * test: enable <misc/tonumber_scan.lua> LuaJIT test * test: remove <misc/uclo.lua> LuaJIT test * test: enable <misc/unordered_jit.lua> LuaJIT test * test: enable <misc/wbarrier.lua> LuaJIT test * test: enable <misc/wbarrier_jit.lua> LuaJIT test * test: enable <misc/wbarrier_obar.lua> LuaJIT test * test: update <LuaJIT-tests/README.md> * test: off JIT for routines in <lang/stackov.lua> * Limit number of string format elements to compile. * Clear stack after print_jit_status() in CLI. * FFI: Workaround for platform dlerror() returning NULL. * test: move profilers tests to subdirectory * test: rename <arm64-ccall-fp-convention.test.lua> * cmake: introduce AppendTestEnvVar macro * test: shrink LUA_PATH environment variable * test: shrink LUA_CPATH and {DY}LD_LIBRARY_PATH * test: skip flaky tests with enabled table bump * test: set LD_PRELOAD only when necessary * test: fix misclib-getmetrics-lapi.test.lua * FFI: Fix __tostring metamethod access to enum cdata value. * Fix limit check in narrow_conv_backprop(). * FFI: Drop finalizer table rehash after GC cycle. * Drop unused function wrapper. * FFI: Fix various issues in recff_cdata_arith. * Add missing coercion when recording select(string, ...) * Fix stack allocation after on-trace stack check. * Restore state when recording __concat metamethod throws an error. * Fix bit op coercion in DUALNUM builds. * FFI: Fix 64 bit shift fold rules. * Limit CSE for IR_CARG to fix loop optimizations. Closes #10290 Closes #10199 Closes #9898 Part of #9398 NO_DOC=LuaJIT submodule bump NO_TEST=LuaJIT submodule bump
-
Andrey Saranchin authored
Since we often search spaces, users, funcs and so on in internal caches that have `read-committed` isolation level (prepared tuples are seen), let's always allow to read prepared tuples of system spaces. Another advantage of such approach is that we never handle MVCC when working with system spaces, so after the commit they will behave in the same way - prepared tuples will be seen. The only difference is that readers of prepared rows will be aborted if the row will be rolled back. By the way, the inconsistency between internal caches and system spaces could lead to crash in some sophisticated scenarios - the commit fixes this problem as well because now system spaces and internal caches are synchronized. Closes #10262 Closes tarantool/security#131 NO_DOC=bugfix (cherry picked from commit b33f17b25de6bcbe3ebc236250976e4a0250e75e)
-
Andrey Saranchin authored
Yielding DDL operations acquire DDL lock so that the space cannot be modified under its feet. However, there is a case when it actually can: if a yielding DDL has started when there is another DDL is being committed and it gets rolled back due to WAL error, `struct space` created by rolled back DDL is deleted - and it's the space being altered by the yielding DDL. In order to fix this problem, let's simply wait for all previous alters to be committed. We could use `wal_sync` to wait for all previous transactions to be committed, but it is more complicated - we need to use `wal_sync` for single instance and `txn_limbo_wait_last_txn` when the limbo queue has an owner. Such approach has more pitfalls and requires more tests to cover all cases. When relying on `struct alter_space` directly, all situations are handled with the same logic. Alternative solutions that we have tried: 1. Throw an error in the case when user tries to alter space when there is another non-committed alter. Such approach breaks applier since it applies rows asynchronously. Trying applier to execute operations synchronously breaks it even harder. 2. Do not use space in `build_index` and `check_format` methods. In this case, there is another problem: rollback order. We have to rollback previous alters firstly, and the in-progress one can be rolled back only after it's over. It breaks fundamental memtx invariant: rollback order must be reverse of replace order. We could try to use `before_replace` triggers for alter, but the patch would be bulky. Closes #10235 NO_DOC=bugfix (cherry picked from commit fee8c5dd6b16471739ed8512ba4137ff2e7274aa)
-
- Oct 16, 2024
-
-
Ilya Verbin authored
All structures with a non-default alignment (set by `alignas()`) must be allocated by `aligned_alloc()`, otherwise an access to such a structure member fill crash, e.g. if compiled with AVX-512 support. See also commit a60ec82d4f07 ("box: fix SIGSEGV on unaligned access to a struct with extended alignment"). Closes #10699 NO_DOC=bugfix NO_CHANGELOG=minor NO_TEST=tested by debug_asan_clang workflow (cherry picked from commit bf091358806ed17bf44efd2cf382a43c0ba49fe0)
-
Sergey Bronnikov authored
GNU GCC compiler has AddressSanitizer support since 4.8.0 [1], but it was unsupported in tarantool's build. The patch fixes a build by GNU GCC with enabled AddressSanitizer. 1. https://gcc.gnu.org/gcc-4.8/changes.html NO_CHANGELOG=build NO_DOC=build NO_TEST=build (cherry picked from commit ef91f92a22c6d7910ecdd00ab14da359343a2ec2)
-
- Oct 15, 2024
-
-
Nikolay Shirokovskiy authored
If opts.identity is NULL and strdup is failed we do NULL pointer dereference when reporting the error. Let's just panic if strdup() failed. While at it replace another strdup() with xstrdup() in this function. Our current approach is to panic on runtime OOM. Closes tarantool/security#128 NO_TEST=issue is not possible after the fix NO_CHANGELOG=not reproducible NO_DOC=bugfix (cherry picked from commit 47b72f44986797466b95b9431a381dbef7dd64fd)
-
- Oct 14, 2024
-
-
Alexander Turenko authored
The reason is that the previous libcurl submodule update in commit 0919f390802f146852b462215327ef03e2730cfc ("third_party: update libcurl from 8.8.0 to 8.10.1") reveals the following regression: NOWRAP ```c $ tarantool -e "require('http.client').new():get('https://google.com') collectgarbage()" tarantool: ./third_party/curl/lib/multi.c:3691: curl_multi_assign: Assertion `!(multi)' failed. Aborted (core dumped) ``` NOWRAP The stacktrace is the following: NOWRAP ```c <...> #4 __assert_fail #5 curl_multi_assign // <- called by us #6 curl_multi_sock_cb // <- this is our callback #7 Curl_multi_pollset_ev #8 cpool_update_shutdown_ev #9 cpool_discard_conn #10 cpool_close_and_destroy_all #11 Curl_cpool_destroy #12 curl_multi_cleanup #13 curl_env_finish // <- destroy the multi handle #14 httpc_env_finish #15 luaT_httpc_cleanup #16 lj_BC_FUNCC #17 gc_call_finalizer #18 gc_finalize #19 gc_onestep #20 lj_gc_fullgc #21 lua_gc #22 lj_cf_collectgarbage #23 lj_BC_FUNCC #24 lua_pcall #25 luaT_call #26 lua_main #27 run_script_f #28 fiber_cxx_invoke #29 fiber_loop #30 coro_init ``` NOWRAP The multi handle is during the destroy, but our `CURLMOPT_SOCKETFUNCTION` callback is invoked and the `curl_multi_assign()` call (invoked to associate a libev watcher to the given file descriptor) fails on the assertion. Everything is as described in https://github.com/curl/curl/issues/15201. The first bad libcurl's commit is [curl-8_10_0-4-g48f61e781][1], but later it was fixed in [curl-8_10_1-241-g461ce6c61][2]. This commit updates libcurl to this revision to fix the regression. Adjusted build options in our build script: * Added `CURL_DISABLE_IPFS=ON`: [curl-8_10_1-57-gce7d0d413][3] * Added `CURL_TEST_BUNDLES=OFF`: [curl-8_10_1-67-g71cf0d1fc][4] * Changed `ENABLE_WEBSOCKETS=OFF` to `CURL_DISABLE_WEBSOCKETS=ON`: [curl-8_10_1-130-gd78e129d5][5] [1]: https://github.com/curl/curl/commit/48f61e781a01e6a8dbc4a347e280644b1c68ab6a [2]: https://github.com/curl/curl/commit/461ce6c6160b86439ddd74c59541231ec9e8558e [3]: https://github.com/curl/curl/commit/ce7d0d41378007eda676c83ad6b86c59870cc9f1 [4]: https://github.com/curl/curl/commit/71cf0d1fca9e1f53524e1545ef0c08d174458d80 [5]: https://github.com/curl/curl/commit/d78e129d50b2d190f1c1bde2ad1f62f02f152db0 NO_DOC=bugfix NO_CHANGELOG=fixes an unreleased commit NO_TEST=can't reproduce without https to add a test case, verified locally (cherry picked from commit fbe6d0a0a40945c42609f5119a007b5c3980c232)
-
Ilya Verbin authored
The type cast is unnecessary and causes false-positive errors: NO_WRAP ``` ./src/box/field_map.c:110:10: runtime error: store to misaligned address 0x507000071082 for type 'uint32_t *' (aka 'unsigned int *'), which requires 4 byte alignment 0x507000071082: note: pointer points here 01 00 00 00 be be be be f0 ff ff ff 02 00 00 00 be be be be be be be be 00 00 00 00 00 00 00 00 ^ SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ./src/box/field_map.c:110:10 ``` NO_WRAP Closes #10631 NO_DOC=bugfix NO_CHANGELOG=minor NO_TEST=tested by debug_asan_clang workflow (cherry picked from commit 5ddbd85cc377a29dc27d01ad06acdc6acc24cc5b)
-
Ilya Verbin authored
New commits: * mempool: fix UBSan errors regarding misaligned stores NO_DOC=submodule bump NO_TEST=submodule bump NO_CHANGELOG=submodule bump (cherry picked from commit 9dd56f49be85dc8a1fe874629711a828835f740c)
-
Ilya Verbin authored
All structures with a non-default alignment (set by `alignas()`) must be allocated by `aligned_alloc()`, otherwise an access to such a structure member fill crash, e.g. if compiled with AVX-512 support. Closes #10215 Part of #10631 NO_DOC=bugfix NO_TEST=tested by debug_asan_clang workflow NO_CHANGELOG=fix is actually not user-visible, because tarantool still doesn't work with enabled AVX-512 (#10671) (cherry picked from commit a60ec82d4f07720148b0724e5feff31f76291b56)
-
Ilya Verbin authored
This reverts commit 3c25c667. `aligned_alloc()` is supported by macOS since 10.15. I believe that we do not support older versions now. NO_DOC=internal NO_TEST=internal NO_CHANGELOG=internal (cherry picked from commit 2f4594f748cff99d15f8f6d603797a308793de86)
-
- Oct 11, 2024
-
-
Alexander Turenko authored
It doesn't work since 2023-11-18. The uploading succeeds, but the website says: > The Coverity Build tool version is no longer supported. Please > download the latest version for your platform from > https://scan.coverity.com/download... It seems, some specific toolset is installed in the `tarantool/testing:debian-buster` image and it was deprecated 11 months ago. Recently the CI workflow starts to fail due to use of the old image with an old CMake in it: > [ 2%] Performing configure step for 'bundled-nanoarrow-project' > -- Building using CMake version: 3.13.4 > -- Configuring incomplete, errors occurred! > CMake Error at CMakeLists.txt:19 (cmake_minimum_required): > CMake 3.14 or higher is required. You are running version 3.13.4 It is likely due to commit 49c160c28c97 ("third_party: initial import of nanoarrow"). Here I refine the workflow file: * Get rid of the custom docker image with preinstalled Coverity toolset. * Use a nice unofficial-coverity-scan GitHub Action ([1]). * Add the `libreadline-dev` dependency installation, because it is needed to build tarantool on Ubuntu 24.04. * Drop related `.test.mk` rules, because it looks more readable to invoke a few commands from the workflow file directly. * Drop testing artifacts uploading that seems a copy-paste from some workflow that runs the tests and the given directory unlikely has any file in our case. * Drop unused step that adds a comment to the pull request. And things seems to start working. At least, after a testing run of the workflow now I see the following status on the website: > Last Build Status: Running. Your build is currently being analyzed [1]: https://github.com/marketplace/actions/unofficial-coverity-scan See also #10651. NO_DOC=developer tools NO_CHANGELOG=see NO_DOC NO_TEST=see NO_DOC (cherry picked from commit f5daacfac84fbea3bb67991fa71ea4e789184ec8)
-