[Tarantool-patches] [PATCH luajit] Fix memory probing allocator to check for valid end address, too.

[Sergey Kaplun]

Hi, Maxim!
Thanks for the fixes!
LGTM, just a few typos.

On 07.06.23, Maxim Kokryashkin wrote:
> 
> Hi!
> Thanks for the review!
>  
> > 
> >>Hi, Maxim!
> >>Thanks for the patch!
> >>The patch is LGTM except a few insiginificant nits below.
> >>
> >>But I'm wondering: can we examine a test case mentioned in the [1]?
> >>I.e. create a really long trace, near the upper bound of the 2GB, so
> >>its results become meaningless? You may take a look into
> >><test/tarantool-tests/gh-4199-gc64-fuse.test.lua> or
> >><test/tarantool-tests/gh-6098-fix-side-exit-patching-on-arm64.test.lua>
> >>for the inspiration.
> >>
> >>This is desired to show actual problem, and not changes in some
> >>synthetic behaviour.
> >As we discussed offline, I’ve added the following comment, branch is force-pushed:
> >=============================================
> >+-- XXX: This test allocates `cdata` objects, but in real world
> >+-- scenarios it can be any object that is allocated with
> >+-- LuaJIT's allocator, including, for example, trace, if it
> >+-- has been allocated close enough to the memory region
> >+-- upper bound and if it is long enough.
> >+--
> >+-- When this issue occurrs with a trace, it may lead to

Typo: s/occurrs/occurs/

> >+-- failures in checks that rely on pointers being 32-bit.

Typo: s/checks/the checks/

> >+-- For example, you can see one here: src/lj_asm_x86.h:370.
> >+--
> >+-- Although it is nice to have a reproducer that shows how
> >+-- that issue can affect a non-synthetic execution, it is really
> >+-- hard to achieve the described situation with traces because
> >+-- allocations are hint-based and there is no robust enough
> >+-- way to create a deterministic test for this behavior.
> >=============================================

<snipped>

> >>
> >>--
> >>Best regards,
> >>Sergey Kaplun
> >--
> >Best regards,
> >Maxim Kokryashkin
> > 

-- 
Best regards,
Sergey Kaplun