From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp40.i.mail.ru (smtp40.i.mail.ru [94.100.177.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 51FA94696C4 for ; Sat, 11 Apr 2020 20:39:09 +0300 (MSK) References: <3595ddfb-4635-61b8-97ae-105f9994087d@tarantool.org> <20200410154050.GD9428@tarantool.org> From: Vladislav Shpilevoy Message-ID: Date: Sat, 11 Apr 2020 19:39:07 +0200 MIME-Version: 1.0 In-Reply-To: <20200410154050.GD9428@tarantool.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Tarantool-patches] [PATCH 1/2] vinyl: init all vars before cleanup in vy_lsm_split_range() List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Nikita Pettik Cc: tarantool-patches@dev.tarantool.org >>> 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. >> 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. > > 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.