From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp52.i.mail.ru (smtp52.i.mail.ru [94.100.177.112]) (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 17ADA452566 for ; Sat, 2 Nov 2019 19:21:09 +0300 (MSK) References: <71d3e28eadd9ca54d5f564ed25d4276d472d5e6d.1572432961.git.imeevma@gmail.com> <20191031152306.GD2636@atlas> <05dc9a5b-f3c8-37f9-3dd7-63cfc966bf11@tarantool.org> From: Vladislav Shpilevoy Message-ID: <4be44137-f646-ed77-d3aa-494cb887dcf3@tarantool.org> Date: Sat, 2 Nov 2019 17:26:49 +0100 MIME-Version: 1.0 In-Reply-To: <05dc9a5b-f3c8-37f9-3dd7-63cfc966bf11@tarantool.org> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [Tarantool-patches] [PATCH v1 1/1] netbox: fix memleak in lbox_tuple_format_new() List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Imeev Mergen , Kirill Yukhin Cc: tarantool-patches@freelists.org, tarantool-patches@dev.tarantool.org Hi! Thanks for the fix! LGTM. On 31/10/2019 17:43, Imeev Mergen wrote: > > On 10/31/19 6:23 PM, Konstantin Osipov wrote: >> * imeevma@tarantool.org [19/10/30 14:03]: >>> Memleak appeared due to the fact that when creating a dictionary >>> its reference count is 1 from the beginning. Later, when the >>> dictionary is used to create tuple_format, its reference counter >>> increased by 1 and it became equal to 2. After removing >>> tuple_format, the reference counter for dict decreased by one, so >>> it became equal to 1. Since ref counter is not equal to 0, dict >>> not deleted, causing a memory leak. >>> >>> Closes #4588 >> I wonder if you could come up with a test case? Is memory used by >> dict accounted in any stats? >> > I did not find anything in box, and I did not see anything about > the statistics in the tuple_dictionary_new() function. Doesn't > look like we accounting this. At the moment, I can’t come up with > a test. > > You think we should add this in stats? > There is no accounting for the heap memory. We tried to add it via symbol replacement, but it didn't work properly. I think we can omit a test here.