From: Igor Munkin via Tarantool-patches <tarantool-patches@dev.tarantool.org>
To: Sergey Kaplun <skaplun@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [PATCH luajit v1] tools: fix luajit-gdb stack dump
Date: Wed, 21 Jul 2021 11:54:11 +0300 [thread overview]
Message-ID: <20210721085411.GJ11494@tarantool.org> (raw)
In-Reply-To: <YPffroa3BrtPJ/Ru@root>
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
next prev parent reply other threads:[~2021-07-21 9:17 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 [this message]
2021-07-22 10:32 ` Sergey Ostanevich via Tarantool-patches
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=20210721085411.GJ11494@tarantool.org \
--to=tarantool-patches@dev.tarantool.org \
--cc=imun@tarantool.org \
--cc=skaplun@tarantool.org \
--subject='Re: [Tarantool-patches] [PATCH luajit v1] tools: fix luajit-gdb stack dump' \
/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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox