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 1DBD86EC55; Thu, 22 Jul 2021 13:32:27 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 1DBD86EC55 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1626949947; bh=KJghScnKu5BYMAtgkyBqi4ll8uKed5dIJlltpm6g0MU=; h=In-Reply-To:Date:References:To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=TvEDEI/W2QtyUXL3cZqe2j//YiwpEaAE0srugofppD3tqVZjvT8GSAG79KMfPEXad cCRIdYtgYCewc6alkggY/mA3rMWPamwfpSk7kbcvEkcRXpYJVqYnC+BcyXWImPZa5P jaVQCrEHObGww804LLSCDCe2Y8mi31LLeIpCSxIM= Received: from smtp31.i.mail.ru (smtp31.i.mail.ru [94.100.177.91]) (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 CB9176EC55 for ; Thu, 22 Jul 2021 13:32:25 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org CB9176EC55 Received: by smtp31.i.mail.ru with esmtpa (envelope-from ) id 1m6W08-0007F9-Rg; Thu, 22 Jul 2021 13:32:25 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) In-Reply-To: <20210721085411.GJ11494@tarantool.org> Date: Thu, 22 Jul 2021 13:32:23 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3E1848F9-799D-4A38-9E7C-CD218ADFDF54@tarantool.org> References: <20210618062234.871-1-skaplun@tarantool.org> <20210720122952.GH11494@tarantool.org> <20210721085411.GJ11494@tarantool.org> To: Igor Munkin X-Mailer: Apple Mail (2.3654.100.0.2.22) X-4EC0790: 10 X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD941C43E597735A9C3A9514C5AE4B3B389A94BDFA06D40730D182A05F5380850402455D279748A07E549586AAFDCFD995138CE11B8402F26677F28F848D763702E X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE72AC9FB60380F23AEEA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637CF05F7050DCA185A8638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D8BB19E5CEAD224E660A158B72F10C2120117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC2EE5AD8F952D28FBA471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F446042972877693876707352033AC447995A7AD18CB629EEF1311BF91D2E47CDBA5A96583BA9C0B312567BB231DD303D21008E29813377AFFFEAFD269A417C69337E82CC2E827F84554CEF50127C277FBC8AE2E8BA83251EDC214901ED5E8D9A59859A8B6A1DCCEB63E2F10FB089D37D7C0E48F6C5571747095F342E88FB05168BE4CE3AF X-C1DE0DAB: 0D63561A33F958A53BC219A140D3E0EB2A00236A96CC07ED75D776DF0231DD53D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA7501A9DF589746230F410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D345CB6DE26F16546678D551F4D170DADA04E16052F55BEFEC21FE7339FC4CF16DFDDC3A0541F39D8B41D7E09C32AA3244C6E154FED4BAB2D95ECD327FA0777A9517C0C08F7987826B9FACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojaAaPr+N/4d2tC2vvN5szCw== X-Mailru-Sender: 3B9A0136629DC912F4AABCEFC589C81E79A033AC1FC22E1B51A88F778D0AA43D4C4DE4592AC8C455AD07DD1419AC565FA614486B47F28B67C5E079CCF3B0523AED31B7EB2E253A9E112434F685709FCF0DA7A0AF5A3A8387 X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH luajit v1] tools: fix luajit-gdb stack dump 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 Ostanevich via Tarantool-patches Reply-To: Sergey Ostanevich Cc: tarantool-patches@dev.tarantool.org Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Hi! Thanks for the patch! I would rather remove all mentions of =E2=80=98bottom loop=E2=80=99 as = we named it at Intel. I'm not a big pro in python, still the =E2=80=98for=E2=80=99 loop = works fine=20 for me: If we can unwind to the next frame - dump it (and further) >>> s=3D[1] >>> for i in s: ... if (i=3D=3D1): ... s.append(2) ... continue ... print(i) ...=20 2 If it is the only one (dummy): >>> s=3D[3] >>> for i in s: ... if (i=3D=3D1): ... s.append(2) ... continue ... print(i) ...=20 3 Does it make sense in this case? Anyways, it=E2=80=99s too much of nitpicking - LGTM in its current = version. Regards, Sergos > On 21 Jul 2021, at 11:54, Igor Munkin wrote: >=20 > Sergey, >=20 > Thanks for the fixes! Everything is perfect now, I'll ask Sergos to > proceed with the review. >=20 > On 21.07.21, Sergey Kaplun wrote: >> Igor, >>=20 >> On 20.07.21, Igor Munkin wrote: >>> Sergey, >>>=20 >>> Thanks for the patch! Nice catch, actually! I wonder, how much = impact >>> this bug made while digging the crash reports. Anyway, LGTM, but >>> consider several nits below. >>=20 >> Actually, not too much. It is the unique situation, when we have = naked >> guest Lua stack without any function call. >=20 > Hm, I guess this bug affects all the cases when dummy frame was used, > but you know it better anyway :) >=20 >>=20 >> Branch is force-pushed with the changes below. >>=20 >>>=20 >>> On 18.06.21, Sergey Kaplun wrote: >=20 > >=20 >>=20 >> Thanks for your comments! >> The new commit message version: >>=20 >> | Dummy frame is the "initial" coroutine state, when the framelink = slot (i.e. >> | L->base - (1 + LJ_FR2)) is the bottom slot of the guest stack >> | (i.e. L->stack). Since coroutine stack unwinding is implemented = via >> | precondition loop, lj-stack doesn't dump the slots for the dummy = frame, since >> | the framelink points to the stack bottom. >> | >> | The output looks like the following: >> | >> | | 0x7fb512ac40:0x7fb512ac70 [ ] 7 slots: Red zone >> | | 0x7fb512ac38 [ M] >> | | 0x7fb512ab28:0x7fb512ac30 [ ] 34 slots: Free stack slots >> | | 0x7fb512ab20 [ T ] >> | | 0x7fb512ab08:0x7fb512ab10 [S ] FRAME: dummy L >> | >> | Python doesn't provide post-condition (do-while) syntax = construction, >> | that fits better for this case, so the unwinding of the topmost = frame is just manually >> | unrolled. >> | >> | As a result of the patch the output looks like the following: >> | >> | | 0x7fb512ac40:0x7fb512ac70 [ ] 7 slots: Red zone >> | | 0x7fb512ac38 [ M] >> | | 0x7fb512ab28:0x7fb512ac30 [ ] 34 slots: Free stack slots >> | | 0x7fb512ab20 [ T ] >> | | 0x7fb512ab18 [ ] VALUE: string 0 = "/tmp/net_box.lua:6: err in ser" @ 0x7fb512ade8 >> | | 0x7fb512ab10 [ B ] VALUE: table @ 0x7fb512ac80 = (asize: 0, hmask: 0x0) >> | | 0x7fb512ab00:0x7fb512ab08 [S ] FRAME: dummy L >=20 > Side note: I guess this is a previous version, since everything is = fine > on the branch. BTW, wording is neat! >=20 >>=20 >=20 > >=20 >>>> diff --git a/src/luajit-gdb.py b/src/luajit-gdb.py >>>> index f1fd6230..a3dad585 100644 >>>> --- a/src/luajit-gdb.py >>>> +++ b/src/luajit-gdb.py >>>> @@ -424,16 +424,26 @@ def dump_stack(L, base=3DNone, top=3DNone): >=20 > >=20 >>=20 >>>=20 >>>> while framelink > mref('TValue *', L['stack']): >>>> - while slot > framelink + LJ_FR2: >>>> - dump +=3D dump_stack_slot(L, slot, base, top) >>>> - slot -=3D 1 >>>> + assert slot =3D=3D framelink + LJ_FR2, "Invalid slot = during frame unwind" >>>=20 >>> Please, use parentheses for assert call. >>=20 >> It's done by design to avoid always true assertions [1]: >>=20 >> | $ python3 >> | Python 3.7.10 (default, Mar 18 2021, 04:43:06) >> | [GCC 9.3.0] on linux >> | Type "help", "copyright", "credits" or "license" for more = information. >> | >>> assert(1!=3D1, "stupid assert") >> | :1: SyntaxWarning: assertion is always true, perhaps remove = parentheses? >=20 > PEBKAC, didn't expect such a surprise here. I looked on the > usage below, but those parentheses are just excess. Everything is fine > here then, and thanks for clarification! >=20 >>=20 >=20 > >=20 >>=20 >> [1]: = https://docs.python.org/3/reference/simple_stmts.html#grammar-token-assert= -stmt >>=20 >> --=20 >> Best regards, >> Sergey Kaplun >=20 > --=20 > Best regards, > IM