From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp37.i.mail.ru (smtp37.i.mail.ru [94.100.177.97]) (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 78838469719 for ; Thu, 27 Feb 2020 23:22:30 +0300 (MSK) Date: Thu, 27 Feb 2020 23:22:29 +0300 From: Kirill Yukhin Message-ID: <20200227202229.hnz7w6c6hbqgf72z@tarantool.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [Tarantool-patches] [PATCH] test: stabilize flaky fiber memory leak detection List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Turenko Cc: tarantool-patches@dev.tarantool.org Hello, On 29 янв 20:03, Alexander Turenko wrote: > After #4736 regression fix (in fact it just reverts the new logic in > small) it is possible again that a fiber's region may hold a memory for > a while, but release it eventually. When the used memory exceeds 128 KiB > threshold, fiber_gc() puts 'garbage' slabs back to slab_cache and > subtracts them from region_used() metric. But until this point those > slabs are accounted in region_used() and so in fiber.info() metrics. > > This commit fixes flakiness of test cases of the following kind: > > | fiber.info()[fiber.self().id()].memory.used -- should be zero > | <...workload...> > | fiber.info()[fiber.self().id()].memory.used -- should be zero > > The problem is that the first `<...>.memory.used` value may be non-zero. > It depends of previous tests that were executed on this tarantool > instance. It is resolved by restarting of a tarantool instance before > such test cases to ensure that there are no 'garbage' slabs in a current > fiber's region. > > Note: This works only if a test case reserves only one slab at the > moment: otherwise some memory may be hold after the case (and so a > memory check after a workload will fail). However it seems that our > cases are small enough to don't trigger this situation. > > Call of region_free() would be enough, but we have no Lua API for it. > > Fixes #4750. I've checked your patch into 2.2, 2.3 and master as temporary workaround. -- Regards, Kirill Yukhin