From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <v.shpilevoy@tarantool.org>
Received: from smtp32.i.mail.ru (smtp32.i.mail.ru [94.100.177.92])
 (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 EDB174696C3
 for <tarantool-patches@dev.tarantool.org>;
 Sat, 18 Apr 2020 02:58:09 +0300 (MSK)
References: <3ee69eaa4ff23647e9ae6fe63e2ae77c427ffe01.1586993218.git.korablev@tarantool.org>
 <574107d5-cb85-1b08-3abf-c2c53497ab5e@tarantool.org>
 <20200416123400.GA6229@tarantool.org>
 <4d22bf0c-a363-719c-4198-46616f42ed48@tarantool.org>
 <20200417200638.GA14084@tarantool.org>
From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Message-ID: <853cb50c-63e1-5961-2495-c3bebd4b9aac@tarantool.org>
Date: Sat, 18 Apr 2020 01:58:08 +0200
MIME-Version: 1.0
In-Reply-To: <20200417200638.GA14084@tarantool.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [Tarantool-patches] [PATCH] box/error: ref error.prev while
 accessing it
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

On 17/04/2020 22:06, Nikita Pettik wrote:
> On 16 Apr 23:17, Vladislav Shpilevoy wrote:
>> Hi! Thanks for the fixes!
>>
>> Now there is a new problem:
>>
>>     value = 2147483647 + 100
>>     e1 = box.error.new(1000, 'Message1')
>>     e2 = box.error.new(1001, 'Message2')
>>     e1:set_prev(e2)
>>     prev = nil
>>     for i = 1, value do prev = e1.prev end
> 
> Oh, if user wrote code like this I guess negative reference
> counter would be fair panishment.

Actually there was a real problem with that, but with tuples.
They have uint32 ref counter, and it really can overflow in Lua
sometimes, when GC is too lazy, and the same tuple is got
many many times from space:get(). That was fixed by separating
one bit as a flag of having an external 'big-ref' uint64 number.

So a user won't write exactly the same stupid code, but it
achievable implicitly, so as you won't even notice.