tuple: allocate formats table statically#10289
Merged
locker merged 1 commit intotarantool:masterfrom Jul 22, 2024
Merged
Conversation
The tuple formats table may be accessed with `tuple_format_by_id()` from any thread, not just tx. For example, it's accessed by a vinyl writer thread when it deletes a tuple. If a thread happens to access the table while it's being reallocated by tx, see `tuple_format_register()`, the accessing thread may crash with a use-after-free or NULL pointer dereference bug, like the one below: ``` # 1 0x64bd45c09e22 in crash_signal_cb+162 # 2 0x76ce74e45320 in __sigaction+80 # 3 0x64bd45ab070c in vy_run_writer_append_stmt+700 # 4 0x64bd45ada32a in vy_task_write_run+234 # 5 0x64bd45ad84fe in vy_task_f+46 # 6 0x64bd45a4aba0 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*)+16 # 7 0x64bd45c13e66 in fiber_loop+70 # 8 0x64bd45e83b9c in coro_init+76 ``` To avoid that, let's make the tuple formats table statically allocated. This shouldn't increase actual memory usage because system memory is allocated lazily, on page fault. The max number of tuple formats isn't that big (64K) to care about the increase in virtual memory usage. Closes tarantool#10278 NO_DOC=bug fix NO_TEST=mt race
mkostoevr
approved these changes
Jul 22, 2024
andreyaksenov
approved these changes
Jul 22, 2024
Member
Author
|
Cherry-picked to 3.1 and 2.11. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The tuple formats table may be accessed with
tuple_format_by_id()from any thread, not just tx. For example, it's accessed by a vinyl writer thread when it deletes a tuple. If a thread happens to access the table while it's being reallocated by tx, seetuple_format_register(), the accessing thread may crash with a use-after-free or NULL pointer dereference bug, like the one below:To avoid that, let's make the tuple formats table statically allocated. This shouldn't increase actual memory usage because system memory is allocated lazily, on page fault. The max number of tuple formats isn't that big (64K) to care about the increase in virtual memory usage.
Closes #10278