From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp63.i.mail.ru (smtp63.i.mail.ru [217.69.128.43]) (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 C172E445320 for ; Wed, 15 Jul 2020 01:48:34 +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: Vladislav Shpilevoy Message-ID: Date: Wed, 15 Jul 2020 00:48:32 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Aleksandr Lyapunov , tarantool-patches@dev.tarantool.org >> 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. But wouldn't it still be the same universal, if you would just take the biggest possible meta size? If we will someday loose the check, it will catch the problem anyway. With a long test I am afraid its fail won't be noticed, since long tests are not run locally by anybody. In CI they are run by coverage only. Anyway, I am ok with the patch.