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 732446EC55; Wed, 21 Jul 2021 12:17:48 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 732446EC55 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1626859068; bh=sWJvFFfLi8aHgioienM3hbYsBCD4hD1uWgfeMULvfZw=; 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=bd5Dzuptz86TPvRqeqDboRv+bZMbxXifdU5OJj/gLYSsFJbi+zQMsOudp1za66fyj CxL4ulM32U53vrQN8yOckx5SuYbJJw2xMwBi7iEix0+ieD6B6Ek3zJkpbG+ACI9HMJ wxNvWSqvyseScECFEo92z6STk457gYLUyCbuzg6A= Received: from smtpng2.i.mail.ru (smtpng2.i.mail.ru [94.100.179.3]) (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 4A1426EC55 for ; Wed, 21 Jul 2021 12:17:47 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 4A1426EC55 Received: by smtpng2.m.smailru.net with esmtpa (envelope-from ) id 1m68MM-0005lw-5W; Wed, 21 Jul 2021 12:17:46 +0300 Date: Wed, 21 Jul 2021 11:54:11 +0300 To: Sergey Kaplun Message-ID: <20210721085411.GJ11494@tarantool.org> References: <20210618062234.871-1-skaplun@tarantool.org> <20210720122952.GH11494@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.10.1 (2018-07-13) X-4EC0790: 10 X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD941C43E597735A9C3038391AAE5FBFA76FBCFDED1455B43CD182A05F538085040EA4D725F5428AC4EFD99306D8EB433703940FDD1FFE4B2D35E9CC4D4C5DE2D68 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7F2EC3597058CFA6DEA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637EDC9855826FBDF5A8638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D89CED86D2452B8A059D5FCE121C7E954E117882F4460429724CE54428C33FAD305F5C1EE8F4F765FCF1175FABE1C0F9B6A471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F446042972877693876707352033AC447995A7AD18C26CFBAC0749D213D2E47CDBA5A96583BA9C0B312567BB231DD303D21008E29813377AFFFEAFD269A417C69337E82CC2E827F84554CEF50127C277FBC8AE2E8BA83251EDC214901ED5E8D9A59859A8B6753C3A5E0A5AB5B7089D37D7C0E48F6C5571747095F342E88FB05168BE4CE3AF X-C1DE0DAB: 0D63561A33F958A5B052183C5CB8C426492E47E6449493023D17DB48B27D3F1ED59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA7501A9DF589746230F410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D34DA1FE609583D493C2F6AD6C3608DE95A867F8403BC99BF14CBAC308840A4E97194187580622DD6DD1D7E09C32AA3244C3654C72A1044B8991FF9782D3D4E15FBE646F07CC2D4F3D8927AC6DF5659F194 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojJX8TSRcb/SjOY9EkPrvbTA== X-Mailru-Sender: 689FA8AB762F7393C37E3C1AEC41BA5D93D11A1E6CC8F71F7F2338A12DD47115A7C8D0F45F857DBFE9F1EFEE2F478337FB559BB5D741EB964C8C2C849690F8E70A04DAD6CC59E33667EA787935ED9F1B 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: Igor Munkin via Tarantool-patches Reply-To: Igor Munkin Cc: tarantool-patches@dev.tarantool.org Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Sergey, Thanks for the fixes! Everything is perfect now, I'll ask Sergos to proceed with the review. On 21.07.21, Sergey Kaplun wrote: > Igor, > > On 20.07.21, Igor Munkin wrote: > > Sergey, > > > > 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. > > Actually, not too much. It is the unique situation, when we have naked > guest Lua stack without any function call. Hm, I guess this bug affects all the cases when dummy frame was used, but you know it better anyway :) > > Branch is force-pushed with the changes below. > > > > > On 18.06.21, Sergey Kaplun wrote: > > Thanks for your comments! > The new commit message version: > > | 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 Side note: I guess this is a previous version, since everything is fine on the branch. BTW, wording is neat! > > > > 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=None, top=None): > > > > > > while framelink > mref('TValue *', L['stack']): > > > - while slot > framelink + LJ_FR2: > > > - dump += dump_stack_slot(L, slot, base, top) > > > - slot -= 1 > > > + assert slot == framelink + LJ_FR2, "Invalid slot during frame unwind" > > > > Please, use parentheses for assert call. > > It's done by design to avoid always true assertions [1]: > > | $ 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!=1, "stupid assert") > | :1: SyntaxWarning: assertion is always true, perhaps remove parentheses? 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! > > > [1]: https://docs.python.org/3/reference/simple_stmts.html#grammar-token-assert-stmt > > -- > Best regards, > Sergey Kaplun -- Best regards, IM