Tarantool development patches archive
 help / color / mirror / Atom feed
From: Sergey Kaplun via Tarantool-patches <tarantool-patches@dev.tarantool.org>
To: Maxim Kokryashkin <max.kokryashkin@gmail.com>
Cc: tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [PATCH luajit] Avoid assertion in case of stack overflow from stitched trace.
Date: Thu, 14 Dec 2023 15:20:53 +0300	[thread overview]
Message-ID: <ZXrzJTLnc4R6cOSG@root> (raw)
In-Reply-To: <20231214114458.17929-1-m.kokryashkin@tarantool.org>

Hi, Maxim!
Thanks for the patch!
Please, consider my comments below.

On 14.12.23, Maxim Kokryashkin wrote:
> From: Mike Pall <mike>
> 
> Reported by Sergey Bronnikov. Fixed by Sergey Kaplun.
> 
> (cherry-picked from commit 1d75cd4d7be638babe6d4e47bf73ea05fc65d81c)
> 
> When we exit from a stitched trace due to the Lua stack overflow
> error, the Lua and JIT stacks are not synchronized, and they
> won't be as long as the mentioned error is raised. Because of

The reason is not the stack synchornization, but the determination of
the bytecode when the error is raised. In the case of stitched trace
(see the dumps below), the last slot in the snapshot map is the argument
for the function to stitch (in our case, ref to 42). Or for the second
trace, we have any other function where the recording is stopped but not
the function where it was started.
So determine bytecode position isn't trivial. And it is better just
return `NO_BCPOS` in such cases.

| Trace 1 start
| ---- TRACE IR
| ....          SNAP   #0   [ ---- ]
| 0001      fun SLOAD  [L ] lit: #0   lit: R
| 0002      tab FLOAD  [L ] ref: 0001 lit: func.env
| 0003      int FLOAD  [L ] ref: 0002 lit: tab.hmask
| 0004   >  int EQ     [C ] ref: 0003 ref: integer 63
| 0005      p32 FLOAD  [L ] ref: 0002 lit: tab.node
| 0006   >  p32 HREFK  [R ] ref: 0005 ref: string "math" @ 0x400061e8 KSLOT: @54
| 0007   >  tab HLOAD  [L ] ref: 0006
| 0008      int FLOAD  [L ] ref: 0007 lit: tab.hmask
| 0009   >  int EQ     [C ] ref: 0008 ref: integer 31
| 0010      p32 FLOAD  [L ] ref: 0007 lit: tab.node
| 0011   >  p32 HREFK  [R ] ref: 0010 ref: string "fmod" @ 0x40006c88 KSLOT: @18
| 0012   >  fun HLOAD  [L ] ref: 0011
| 0013   >  fun EQ     [C ] ref: 0012 ref: fast function #58
| ....          SNAP   #1   [ ---- {trace 0x1 @ 0x400271d8} contpc ftsz | {number 42} {number 42} ]
| 0014          NOP    [N ]
|
| Trace 2 start
| ---- TRACE IR
| ....          SNAP   #0   [ ---- ]
| 0001      fun SLOAD  [L ] lit: #0   lit: R
| 0002   >  fun EQ     [C ] ref: 0001 ref: Lua function @ 0x400157f0, 1 upvalues, "@../master/test/tarantool-tests/lj-913-so-stitched.test.lua":11
| ....          SNAP   #1   [ ftsz | ftsz | ]
| 0003          NOP    [N ]

> that, we get the incorrect bytecode instruction in
> `debug_framepc`. This patch fixes this behavior, so the
> `debug_framepc` now returns `NO_BCPOS` for this case.
> 
> Maxim Kokryashkin:
> * added the description and the test for the problem
> 
> Part of tarantool/tarantool#9145
> ---
> Branch: https://github.com/tarantool/luajit/tree/fckxorg/lj-913-avoid-assertion-stkov-from-stitched-trace
> PR: https://github.com/tarantool/tarantool/pull/9484
> Issues: https://github.com/tarantool/tarantool/issues/9145
> https://github.com/LuaJIT/LuaJIT/issues/913
> 
>  src/lj_debug.c                                |  9 +++++---
>  ...-913-stackoverflow-stitched-trace.test.lua | 23 +++++++++++++++++++
>  2 files changed, 29 insertions(+), 3 deletions(-)
>  create mode 100644 test/tarantool-tests/lj-913-stackoverflow-stitched-trace.test.lua
> 
> diff --git a/src/lj_debug.c b/src/lj_debug.c
> index 46c442c6..107f464c 100644
> --- a/src/lj_debug.c
> +++ b/src/lj_debug.c

<snipped>

> diff --git a/test/tarantool-tests/lj-913-stackoverflow-stitched-trace.test.lua b/test/tarantool-tests/lj-913-stackoverflow-stitched-trace.test.lua
> new file mode 100644
> index 00000000..3c12f0d9
> --- /dev/null
> +++ b/test/tarantool-tests/lj-913-stackoverflow-stitched-trace.test.lua
> @@ -0,0 +1,23 @@
> +local tap = require('tap')
> +-- Test to demonstrate the incorrect LuaJIT behavior when exiting
> +-- from a snapshot for stitched trace.
> +local test = tap.test('lj-913-stackoverflow-stitched-trace'):skipcond({
> +  ['Test requires JIT enabled'] = not jit.status(),
> +})
> +
> +test:plan(3)
> +
> +-- Recursion to cause stack overflow.
> +local function callee()
> +  -- `math.fmod()` is NYI, so trace will be stitched here.
> +  local _ = math.fmod(42, 42)

We don't need this `_` variable here. Just using `math.fmod()` is
enough.

> +  callee()
> +end
> +
> +local st, err = pcall(callee)
> +
> +test:ok(true, 'assertion is not triggered')
> +test:ok(not st, 'error happened')
> +test:like(err, 'stack overflow', 'stack overflow happened')
> +
> +test:done(true)
> --
> 2.43.0
> 

-- 
Best regards,
Sergey Kaplun

  reply	other threads:[~2023-12-14 12:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-14 11:44 Maxim Kokryashkin via Tarantool-patches
2023-12-14 12:20 ` Sergey Kaplun via Tarantool-patches [this message]
2023-12-21 12:01   ` Maxim Kokryashkin via Tarantool-patches
2024-01-09 13:03     ` Sergey Kaplun via Tarantool-patches
2023-12-19 11:57 ` Sergey Bronnikov via Tarantool-patches
2024-02-15 13:42 ` 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=ZXrzJTLnc4R6cOSG@root \
    --to=tarantool-patches@dev.tarantool.org \
    --cc=max.kokryashkin@gmail.com \
    --cc=skaplun@tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH luajit] Avoid assertion in case of stack overflow from stitched trace.' \
    /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