From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org> To: Nikita Pettik <korablev@tarantool.org>, tarantool-patches@dev.tarantool.org Subject: Re: [Tarantool-patches] [PATCH 1/2] vinyl: init all vars before cleanup in vy_lsm_split_range() Date: Fri, 10 Apr 2020 17:13:12 +0200 [thread overview] Message-ID: <3595ddfb-4635-61b8-97ae-105f9994087d@tarantool.org> (raw) In-Reply-To: <bd03396847c1b5a5657429af2dae35d67af3a3c8.1586381297.git.korablev@tarantool.org> Hi! Thanks for the patch! See 3 comments below. > diff --git a/src/box/vy_lsm.c b/src/box/vy_lsm.c > index 3d3f41b7a..04c9926a8 100644 > --- a/src/box/vy_lsm.c > +++ b/src/box/vy_lsm.c > @@ -134,6 +134,11 @@ vy_stmt_alloc(struct tuple_format *format, uint32_t bsize) > { > uint32_t total_size = sizeof(struct vy_stmt) + format->field_map_size + > bsize; > + struct errinj *inj = errinj(ERRINJ_VY_MAX_TUPLE_SIZE, ERRINJ_INT); > + if (inj != NULL && inj->iparam >= 0) { > + if (inj->iparam-- == 0) 1. You set ERRINJ_VY_MAX_TUPLE_SIZE to an integer. Why not to a boolean, which would set it to false instead of decrement? That would make it clear the injection works only once. Also it looks too artificial. The injection basically simulates a tuple with too big size which was inserted bypassing max_tuple_size check, and suddenly it was checked here, already after insertion. Better add an OOM injection for malloc a few lines below, would be more correct. > + total_size = vy_max_tuple_size + 1; > + } > if (unlikely(total_size > vy_max_tuple_size)) { > diag_set(ClientError, ER_VINYL_MAX_TUPLE_SIZE, > (unsigned) total_size); > diff --git a/test/vinyl/gh-4864-stmt-alloc-fail-compact.result b/test/vinyl/gh-4864-stmt-alloc-fail-compact.result > new file mode 100644 > index 000000000..2c03697f6 > --- /dev/null > +++ b/test/vinyl/gh-4864-stmt-alloc-fail-compact.result > @@ -0,0 +1,93 @@ > +-- test-run result file version 2 > +test_run = require('test_run').new() > + | --- > + | ... > +fiber = require('fiber') > + | --- > + | ... > +digest = require('digest') > + | --- > + | ... > + > +s = box.schema.space.create('test', {engine = 'vinyl'}) > + | --- > + | ... > +_ = s:create_index('pk', {run_count_per_level = 100, page_size = 128, range_size = 1024}) > + | --- > + | ... > + > +test_run:cmd("setopt delimiter ';'") > + | --- > + | - true > + | ... > +function dump(big) > + local step = big and 1 or 5 > + for i = 1, 20, step do > + s:replace{i, digest.urandom(1000)} > + end > + box.snapshot() > +end; > + | --- > + | ... > + > +function compact() > + s.index.pk:compact() > + repeat > + fiber.sleep(0.001) > + local info = s.index.pk:stat() > + until info.range_count == info.run_count > +end; > + | --- > + | ... > +test_run:cmd("setopt delimiter ''"); > + | --- > + | - true > + | ... > + > +-- The first run should be big enough to prevent major compaction > +-- on the next dump, because run_count_per_level is ignored on the > +-- last level. > +-- > +dump(true) > + | --- > + | ... > +dump() > + | --- > + | ... > +-- 1 range, 2 runs 2. Can you add an assertion, that it is really 1 range and 2 runs? To be sure that the test won't become useless in future if suddenly something will change there. > + > +compact() > + | --- > + | ... > +-- 1 range, 1 run after compaction > + > +dump() > + | --- > + | ... > +-- 1 range, 2 runs > + > +errinj = box.error.injection > + | --- > + | ... > +errinj.set('ERRINJ_VY_MAX_TUPLE_SIZE', 0) > + | --- > + | - ok > + | ... > +-- Should finish successfully despite vy_stmt_alloc() fail. > +-- > +compact() > + | --- > + | ... > +-- 1 range, 1 run > +s.index.pk:stat().range_count > + | --- > + | - 1 > + | ... > +s.index.pk:stat().run_count 3. I would add an assertion/print, that ERRINJ_VY_MAX_TUPLE_SIZE (or whatever will be used after the review) is changed back to off, and then change it to off again anyway. Because if the test won't hit the errinj because of something in future, the errinj will be left set, and we won't notice that here. Also it will make all next vinyl tests running in the same job fail in very surprising ways. The same for the next commit. > + | --- > + | - 1 > + | ... > + > +s:drop() > + | --- > + | ...
next prev parent reply other threads:[~2020-04-10 15:13 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-04-08 21:37 [Tarantool-patches] [PATCH 0/2] vinyl: fix uninitialized memory accesses Nikita Pettik 2020-04-08 21:37 ` [Tarantool-patches] [PATCH 1/2] vinyl: init all vars before cleanup in vy_lsm_split_range() Nikita Pettik 2020-04-09 8:18 ` Konstantin Osipov 2020-04-09 10:55 ` Nikita Pettik 2020-04-09 11:07 ` Konstantin Osipov 2020-04-09 11:26 ` Nikita Pettik 2020-04-10 15:13 ` Vladislav Shpilevoy [this message] 2020-04-10 15:40 ` Nikita Pettik 2020-04-10 18:24 ` Nikita Pettik 2020-04-11 17:39 ` Vladislav Shpilevoy 2020-04-13 22:29 ` Nikita Pettik 2020-04-14 21:40 ` Nikita Pettik 2020-04-08 21:37 ` [Tarantool-patches] [PATCH 2/2] vinyl: clean-up read views if *_build_history() fails Nikita Pettik 2020-04-09 8:19 ` Konstantin Osipov 2020-04-09 11:09 ` Nikita Pettik 2020-04-10 15:13 ` Vladislav Shpilevoy 2020-04-10 15:47 ` Nikita Pettik 2020-04-10 21:45 ` Nikita Pettik 2020-04-10 22:32 ` Vladislav Shpilevoy 2020-04-11 17:30 ` Konstantin Osipov 2020-04-13 22:31 ` Nikita Pettik 2020-04-13 22:35 ` Konstantin Osipov 2020-04-13 22:11 ` Nikita Pettik 2020-04-11 17:39 ` Vladislav Shpilevoy
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=3595ddfb-4635-61b8-97ae-105f9994087d@tarantool.org \ --to=v.shpilevoy@tarantool.org \ --cc=korablev@tarantool.org \ --cc=tarantool-patches@dev.tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH 1/2] vinyl: init all vars before cleanup in vy_lsm_split_range()' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox