From: Nikita Pettik <korablev@tarantool.org> To: Vladislav Shpilevoy <v.shpilevoy@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() Date: Tue, 14 Apr 2020 21:40:44 +0000 [thread overview] Message-ID: <20200414214044.GA30418@tarantool.org> (raw) In-Reply-To: <20200413222909.GB24818@tarantool.org> On 13 Apr 22:29, Nikita Pettik wrote: > On 11 Apr 19:39, Vladislav Shpilevoy wrote: > > >>> 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. > > > > > > Cause integer allows setting delay of vy_stmt_alloc() failure. > > > For instance, I don't want first invocation to vy_stmt_alloc() > > > fail, but the second, third or tenth one - it may turn out to be > > > vital. This patch fixes bug when first call of vy_stmt_alloc() > > > during compaction fails; the next patch - if tenth call of > > > vy_stmt_alloc() fails. > > > > Nope, in the next patch you use 0 too. Moreover, when I changed it > > to 10, I got the test hanging in 100% CPU. Regardless of with the > > fix or without. > > It should have been 10. Kind of strange since it is exactly this > value that helped me to reveal this bug. Mb it is still unpredictable > consequences of invalid memory access. I will investigate and test on > my mac before next updates. Thx. > > > >> 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. I've tested on my mac: without fix Tarantool really gets stuck. But when I run process in gdb/lldb it always crashes (in the same place as on my linux machine - when accessing invalid memory). So I assume accessing invalid memory may result in any behaviour whether it is infinite loop or crash. With applied fix everything works OK on both linux and mac. > > > Konstantint said, that squashing two upserts of size 'x' may result > > > in new vy_stmt with size > 'x'. Despite the fact that I did not > > > attempt at reproducing this statement, I saw these errors appearing > > > on production machine during compaction. I do not know the exact reason > > > why they revealed, but it is a fact. > > > > And still this particular test does not use any upserts. So OOM here > > is more likely to happen than max tuple size violation. > > > > >> Better add an OOM injection for malloc a few lines below, would be more > > >> correct.
next prev parent reply other threads:[~2020-04-14 21:40 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 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 [this message] 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=20200414214044.GA30418@tarantool.org \ --to=korablev@tarantool.org \ --cc=tarantool-patches@dev.tarantool.org \ --cc=v.shpilevoy@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