Tarantool development patches archive
 help / color / mirror / Atom feed
From: Sergey Ostanevich via Tarantool-patches <tarantool-patches@dev.tarantool.org>
To: Igor Munkin <imun@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [PATCH luajit v1] tools: fix luajit-gdb stack dump
Date: Thu, 22 Jul 2021 13:32:23 +0300
Message-ID: <3E1848F9-799D-4A38-9E7C-CD218ADFDF54@tarantool.org> (raw)
In-Reply-To: <20210721085411.GJ11494@tarantool.org>

Hi!

Thanks for the patch!

I would rather remove all mentions of ‘bottom loop’ as we named it at
Intel. I'm not a big pro in python, still the ‘for’ loop works fine 
for me:

If we can unwind to the next frame - dump it (and further)

>>> s=[1]
>>> for i in s:
...   if (i==1):
...     s.append(2)
...     continue
...   print(i)
... 
2

If it is the only one (dummy):

>>> s=[3]
>>> for i in s:
...   if (i==1):
...     s.append(2)
...     continue
...   print(i)
... 
3

Does it make sense in this case?

Anyways, it’s too much of nitpicking - LGTM in its current version.

Regards,
Sergos


> On 21 Jul 2021, at 11:54, Igor Munkin <imun@tarantool.org> wrote:
> 
> 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:
> 
> <snipped>
> 
>> 
>> 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!
> 
>> 
> 
> <snipped>
> 
>>>> 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):
> 
> <snipped>
> 
>> 
>>> 
>>>>     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")
>> | <stdin>:1: SyntaxWarning: assertion is always true, perhaps remove parentheses?
> 
> PEBKAC, didn't expect such a surprise here. I looked on the <assert>
> usage below, but those parentheses are just excess. Everything is fine
> here then, and thanks for clarification!
> 
>> 
> 
> <snipped>
> 
>> 
>> [1]: https://docs.python.org/3/reference/simple_stmts.html#grammar-token-assert-stmt
>> 
>> -- 
>> Best regards,
>> Sergey Kaplun
> 
> -- 
> Best regards,
> IM


  reply	other threads:[~2021-07-22 10:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-18  6:22 Sergey Kaplun via Tarantool-patches
2021-07-05  7:03 ` Sergey Kaplun via Tarantool-patches
2021-07-20 12:29 ` Igor Munkin via Tarantool-patches
2021-07-21  8:49   ` Sergey Kaplun via Tarantool-patches
2021-07-21  8:54     ` Igor Munkin via Tarantool-patches
2021-07-22 10:32       ` Sergey Ostanevich via Tarantool-patches [this message]
2021-07-22 11:48         ` Igor Munkin via Tarantool-patches
2021-07-22 12:51           ` Sergey Ostanevich via Tarantool-patches
2021-07-21  9:02     ` Sergey Kaplun via Tarantool-patches
2021-07-22 13:34 ` Igor Munkin via Tarantool-patches

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3E1848F9-799D-4A38-9E7C-CD218ADFDF54@tarantool.org \
    --to=tarantool-patches@dev.tarantool.org \
    --cc=imun@tarantool.org \
    --cc=sergos@tarantool.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Tarantool development patches archive

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://lists.tarantool.org/tarantool-patches/0 tarantool-patches/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 tarantool-patches tarantool-patches/ https://lists.tarantool.org/tarantool-patches \
		tarantool-patches@dev.tarantool.org.
	public-inbox-index tarantool-patches

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git