From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-f68.google.com (mail-lf1-f68.google.com [209.85.167.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 4779846970E for ; Fri, 31 Jan 2020 11:18:58 +0300 (MSK) Received: by mail-lf1-f68.google.com with SMTP id 9so4216013lfq.10 for ; Fri, 31 Jan 2020 00:18:58 -0800 (PST) Date: Fri, 31 Jan 2020 11:18:55 +0300 From: Konstantin Osipov Message-ID: <20200131081855.GB10740@atlas> References: <591f17842bd4138b5598d6d69822195daef63375.1579541242.git.i.kosarev@tarantool.org> <20200121103258.GG82780@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200121103258.GG82780@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH v3 1/2] b-tree: return NULL on matras_alloc fail List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Nikita Pettik Cc: tarantool-patches@dev.tarantool.org, v.shpilevoy@tarantool.org * Nikita Pettik [20/01/21 13:37]: > On 20 Jan 21:13, Ilya Kosarev wrote: > > In bps_tree_create_leaf we use matras_alloc in case > > bps_tree_garbage_pop didn't work out. However it also might not > > succeed. Then we need to return NULL instead of dereferencing NULL > > pointer. I don't understand the attempt to fix it. The reason the allocations are not checked - most likely -because BPS should refuse to even begin an operation if there is not enough memory in matras. Most likely Alexander Lyapunov was relying on that, and this is why you don't have these checks all over bps code. -- Konstantin Osipov, Moscow, Russia