tarantool / tarantool / 12812375321

88%

master: 88%

Build Type

push

github

Committed by sergepetrenko

Commit Message

replication: fix crash on non-empty limbo exit

Normally it couldn't happen with user-originated transactions,
because they were always attached to a fiber, and the shutdown
code would panic if any user fibers couldn't be cancelled and
joined fast enough.

However it could always happen with applier txns (async, no fiber)
and now is possible with `wait='none'` and `'submit'` commit
modes.

When this happened, at least 2 situations were possible:

- The txn was not synchro and was just ignored, deleted together
      with the memory allocator.

- The txn was synchro and waiting for ACKs. It was "freed" (put
      back into the txn cache) without completion, and its
      triggers would leak.

- The txn was synchro and being written to WAL right now. Then it
      was also freed (including its region memory removal), and
      the WAL thread would sometimes crash on use-after-free.

The last case was a problem.

The solution is to reorder the initialization and destruction of
the limbo and related modules.

Specifically, lets do the following:

- Make the limbo a part of box_storage_init/shutdown/free. Indeed,
    the limbo doesn't make sense without the storage anyway.

- Destroy the limbo after WAL. To make sure that the freed txns
    aren't used by the WAL thread.

- Destroy the limbo before the engine. Because memtx engine
    destroys its tuples regardless of their ref counts, making all
    not yet freed `txn_stmt` objects invalid (they would contain
    dangling pointers to `old_tuple` and `new_tuple`).

Then the txns are not used and are still valid at the time the
limbo gets destroyed.

Part of #10766

NO_DOC=bugfix

(cherry picked from commit 91ff7c899)

Run Details

69670 of 123538 branches covered (56.4%)

4 of 4 new or added lines in 2 files covered. (100.0%)

36 existing lines in 13 files now uncovered.

102639 of 117492 relevant lines covered (87.36%)

2449464.51 hits per line