From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id 0C1126F158; Thu, 18 Aug 2022 11:29:50 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 0C1126F158 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1660811390; bh=Pc3bl0/PBIoUZiUGbJXDS0O7/2dErI5geapkXMjliik=; h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=kj9E0kcc+TB5b4TlaBfcGh0GyJnpiGj5IBRxLQPZoYq/q194rfjZrXrpWKWZoh9fq NGX1iVgakFoYxOhxXkvxSE82c3kPyOie5nVEPnfK8PKtv8ANN4BsKpfClalNOdc54H 88r0UcCWSpUBfz4P5gGVJitsNMuDXvsZMQnYOA/U= Received: from smtpng3.i.mail.ru (smtpng3.i.mail.ru [94.100.177.149]) (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 1914B6F158 for ; Thu, 18 Aug 2022 11:29:49 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 1914B6F158 Received: by smtpng3.m.smailru.net with esmtpa (envelope-from ) id 1oOauS-0008AJ-0N; Thu, 18 Aug 2022 11:29:48 +0300 Date: Thu, 18 Aug 2022 11:27:15 +0300 To: Sergey Bronnikov Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Mailru-Src: smtp X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD999D8F08CF16C6CA778D25EAFB9B704D76F45BF89FAEEA5B700894C459B0CD1B97992217A3E4A48AFCC77AD5B4EE14DBEEAFD0BE2EDDDCE368B54489E99F5676F X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE73B44982FA5E78411EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006378997215BCAA11D778638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D8DDBE5B2F153ADC86EAC04A830D66F4A5117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC00AB816903775DDCA471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F446042972877693876707352033AC447995A7AD18CB629EEF1311BF91D2E47CDBA5A96583BA9C0B312567BB231DD303D21008E29813377AFFFEAFD269A417C69337E82CC2E827F84554CEF50127C277FBC8AE2E8BA83251EDC214901ED5E8D9A59859A8B67ECBC18655D52CDF089D37D7C0E48F6C5571747095F342E88FB05168BE4CE3AF X-C1DE0DAB: 9604B64F49C60606AD91A466A1DEF99B296C473AB1E142185AC9E3593CE4B31AB1881A6453793CE9274300E5CE05BD4401A9E91200F654B0C7A0BC55FA0FE5FC569FB34D613569801A76E34DBC021F29CA95F8303746428FB1881A6453793CE9C32612AADDFBE06133F7A9E5587C79A693EDB24507CE13387DFF0A840B692CF8 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D34060C3C6DE316ECE4B963AC33CC2699EF331378C59706E724BD91B78D40E6DDDCD60FB8805BE57EB21D7E09C32AA3244C107BF68612B1984477017F5A81CAC8E469B6CAE0477E908DFACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2bioj7Jv35gwMd2O00FsXYIV12A== X-DA7885C5: E1B75B62D8F9B7E47E0501EC6262CE5BF8758C86FF365639A2B78A91E14A0FE5262E2D401490A4A0DB037EFA58388B346E8BC1A9835FDE71 X-Mailru-Sender: 689FA8AB762F7393CC2E0F076E87284E3FB7F0B11BDC3D5287A999B1586BCEF70FBE9A32752B8C9C2AA642CC12EC09F1FB559BB5D741EB962F61BD320559CF1EFD657A8799238ED55FEEDEB644C299C0ED14614B50AE0675 X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH luajit 1/8] test: introduce LUAJIT_TEST_VARDIR variable X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Sergey Kaplun via Tarantool-patches Reply-To: Sergey Kaplun Cc: tarantool-patches@dev.tarantool.org Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Hi, Igor! Thanks for the patch! LGTM, after fixes for commit message mentioned by Sergey. On 15.08.22, Sergey Bronnikov wrote: > Igor, > >  thanks for the patch. See my comments inline. > > On 11.08.2022 14:17, Igor Munkin wrote: > > Before the patch both memprof and sysprof artefacts are generated within > > the binary artefacts tree (i.e. in the same directory LuaJIT binary is > > generated). However, more convenient way is producing these temporary > > profiles in a separate directory (e.g. located on the partition with > > more strict space limits). As a result of the patch all memprof and > > sysprof test chunks consider LUAJIT_TEST_VARDIR environment variable to > > set the directory where test profiles are generated. For the case when > > LUAJIT_TEST_VARDIR is not set, everything works as before. > > Commit message is inconsistent a bit with a patch itself. > > As far as I understand many hunks are not related to introducing > LUAJIT_TEST_VARDIR. > > Probably it is better to change commit one-line message from "test: > introduce LUAJIT_TEST_VARDIR variable" > > to something like "test: refactoring and introduce LUAJIT_TEST_VARDIR > variable". It allows to keep patch Agree with Sergey here. This patch is more about prerequisites for this variable. > > as is and change expectations for those who will look at your patch. > > > > > > Part of tarantool/tarantool#7472 > > > > Signed-off-by: Igor Munkin > > --- > > .../gh-5813-resolving-of-c-symbols.test.lua | 6 +++-- > > .../misclib-memprof-lapi.test.lua | 22 ++++++++++--------- > > .../misclib-sysprof-lapi.test.lua | 8 ++++--- > > test/tarantool-tests/utils.lua | 12 ++++++++++ > > 4 files changed, 33 insertions(+), 15 deletions(-) > > > > diff --git a/test/tarantool-tests/gh-5813-resolving-of-c-symbols.test.lua b/test/tarantool-tests/gh-5813-resolving-of-c-symbols.test.lua > > index d589dddf..e0b6d86d 100644 > > --- a/test/tarantool-tests/gh-5813-resolving-of-c-symbols.test.lua > > +++ b/test/tarantool-tests/gh-5813-resolving-of-c-symbols.test.lua > > @@ -1,5 +1,7 @@ > > -- Memprof is implemented for x86 and x64 architectures only. > > -require("utils").skipcond( > > +local utils = require("utils") > > + > > +utils.skipcond( > > jit.arch ~= "x86" and jit.arch ~= "x64" or jit.os ~= "Linux", > > jit.arch.." architecture or "..jit.os.. > > " OS is NIY for memprof c symbols resolving" > > @@ -18,7 +20,7 @@ local testboth = require "resboth" > > local testhash = require "reshash" > > local testgnuhash = require "resgnuhash" > > > > -local TMP_BINFILE = arg[0]:gsub(".+/([^/]+)%.test%.lua$", "%.%1.memprofdata.tmp.bin") > > +local TMP_BINFILE = utils.profilename("memprofdata.tmp.bin") > > > > local function tree_contains(node, name) > > if node == nil then > > diff --git a/test/tarantool-tests/misclib-memprof-lapi.test.lua b/test/tarantool-tests/misclib-memprof-lapi.test.lua > > index a11f0be1..bae0c27c 100644 > > --- a/test/tarantool-tests/misclib-memprof-lapi.test.lua > > +++ b/test/tarantool-tests/misclib-memprof-lapi.test.lua > > @@ -1,5 +1,7 @@ > > -- Memprof is implemented for x86 and x64 architectures only. > > -require("utils").skipcond( > > +local utils = require("utils") > > + > > +utils.skipcond( > > jit.arch ~= "x86" and jit.arch ~= "x64", > > jit.arch.." architecture is NIY for memprof" > > ) > > @@ -26,8 +28,8 @@ local memprof = require "memprof.parse" > > local process = require "memprof.process" > > local symtab = require "utils.symtab" > > > > -local TMP_BINFILE = arg[0]:gsub(".+/([^/]+)%.test%.lua$", "%.%1.memprofdata.tmp.bin") > > -local BAD_PATH = arg[0]:gsub(".+/([^/]+)%.test%.lua$", "%1/memprofdata.tmp.bin") > > +local TMP_BINFILE = utils.profilename("memprofdata.tmp.bin") > > +local BAD_PATH = utils.profilename("memprofdata/tmp.bin") > > local SRC_PATH = "@"..arg[0] > > > > local function default_payload() > > @@ -189,9 +191,9 @@ test:test("output", function(subtest) > > -- one is the number of allocations. 1 event - alocation of > > -- table by itself + 1 allocation of array part as far it is > > -- bigger than LJ_MAX_COLOSIZE (16). > > - subtest:ok(check_alloc_report(alloc, { line = 35, linedefined = 33 }, 2)) > > + subtest:ok(check_alloc_report(alloc, { line = 37, linedefined = 35 }, 2)) > > -- 20 strings allocations. > > - subtest:ok(check_alloc_report(alloc, { line = 40, linedefined = 33 }, 20)) > > + subtest:ok(check_alloc_report(alloc, { line = 42, linedefined = 35 }, 20)) > What are these magic numbers mean and why we should change them for > introducing LUAJIT_TEST_VARDIR? Yes, this is nasty problems with the lines where allocation happens. As far as we add new lines before tested function these numbers change. > > > > -- Collect all previous allocated objects. > > subtest:ok(free.INTERNAL.num == 22) > > return M -- Best regards, Sergey Kaplun