tuple: allocate formats table statically
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 #10278 NO_DOC=bug fix NO_TEST=mt race
Showing
- changelogs/unreleased/gh-10278-vy-tuple-format-lookup-fix.md 4 additions, 0 deletionschangelogs/unreleased/gh-10278-vy-tuple-format-lookup-fix.md
- src/box/tuple_format.c 3 additions, 24 deletionssrc/box/tuple_format.c
- src/box/tuple_format.h 1 addition, 1 deletionsrc/box/tuple_format.h
- test/wal_off/alter.result 1 addition, 1 deletiontest/wal_off/alter.result
Loading
Please register or sign in to comment