From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149]) (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 3DA50445320 for ; Tue, 14 Jul 2020 20:09:18 +0300 (MSK) References: <1594221263-6228-1-git-send-email-alyapunov@tarantool.org> <1594221263-6228-3-git-send-email-alyapunov@tarantool.org> <6ee9cb95-5fca-2707-d47e-8d1b4b2105f3@tarantool.org> From: Aleksandr Lyapunov Message-ID: Date: Tue, 14 Jul 2020 20:09:16 +0300 MIME-Version: 1.0 In-Reply-To: <6ee9cb95-5fca-2707-d47e-8d1b4b2105f3@tarantool.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Re: [Tarantool-patches] [PATCH 02/16] Check data_offset overflow in struct tuple List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladislav Shpilevoy , tarantool-patches@dev.tarantool.org Hi! thanks for review! see my replys below. On 12.07.2020 20:15, Vladislav Shpilevoy wrote: > > So this test would crash even without multikeys? With just too many > field offsets? How long does it work? Yes, the bug was introduced long time before multikeys. The test runs 1.3 second on my comp, and my comp is quite good. > > And why do you need to try to many combinations, if you know which one was > going to crash before the patch? I want the test to be more universal. For example in further commits I grab one bit from data_offset for is_dirty flag, and the test still checks the possible crash while max allowed data_offset have changed.