From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp57.i.mail.ru (smtp57.i.mail.ru [217.69.128.37]) (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 7AD544696C3 for ; Mon, 20 Apr 2020 17:35:25 +0300 (MSK) Date: Mon, 20 Apr 2020 14:35:24 +0000 From: Nikita Pettik Message-ID: <20200420143524.GA27460@tarantool.org> References: <20200420142237.jrnslig6pusym6nd@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200420142237.jrnslig6pusym6nd@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH v2 0/2] Stacked diagnostic area follow-ups List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kirill Yukhin Cc: tarantool-patches@dev.tarantool.org, v.shpilevoy@tarantool.org On 20 Apr 17:22, Kirill Yukhin wrote: > Hello, > > On 17 апр 23:16, Nikita Pettik wrote: > > Branch: https://github.com/tarantool/tarantool/tree/np/gh-4887-ref-error-on-prev > > Issue: https://github.com/tarantool/tarantool/issues/4887 > > > > Changes in v2: > > > > - modified test so that now it uses weak references to check that > > gc collected error objects (i.e. there's no memory leaks); > > - added overflow check in error_ref() so that after 2^32 calls > > of box.error.last() or error:prev() error object won't contain > > broken reference counter. > > > > Nikita Pettik (2): > > box/error: don't allow overflow of error ref counter > > box/error: ref error.prev while accessing it > > I've checked your patchset into master. > > However, looks like it'd be better to just replace int32 to > int64 and avoid problems if GC64. Could you please specify which problems you are talking about? Current fix simply prevents from overflow, so it does not introduce any other problems. Meanwhile users who ref single error more than 2^32 times are likely doing smth wrong so Lua error notifying them aboit it is a good practice IMHO. > Since I've already checked the patch in, could you please > prepare a patch which will revert functional changes of 2/2 > and use int64 instead? > > -- > Regards, Kirill Yukhin