From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <v.shpilevoy@tarantool.org>
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 <tarantool-patches@dev.tarantool.org>;
Sat, 11 Apr 2020 20:39:09 +0300 (MSK)
References: <cover.1586381297.git.korablev@tarantool.org>
<bd03396847c1b5a5657429af2dae35d67af3a3c8.1586381297.git.korablev@tarantool.org>
<3595ddfb-4635-61b8-97ae-105f9994087d@tarantool.org>
<20200410154050.GD9428@tarantool.org>
From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Message-ID: <fcd5b6c4-a362-8ce5-a910-7b2ea85f1345@tarantool.org>
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 <tarantool-patches.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>,
<mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/>
List-Post: <mailto:tarantool-patches@dev.tarantool.org>
List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>,
<mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe>
To: Nikita Pettik <korablev@tarantool.org>
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.