lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Wed, 12 Dec 2018 at 13:55, nobody <> wrote:
> …like [===…===[a]===…===] cause all sorts of weird behavior (incl.
> crashes) in 5.3.x / 5.4 (git HEAD).  Try
> local eqs = ("="):rep(0x3ffffffe)
> local code = "return ["..eqs.."[a]"..eqs.."]"
> print(#assert(load(code))())
> It might segfault, it might print a huge number instead of 1 (or, minus
> the '#', print 'a]===…===]<<garbage>>' instead of a single 'a').
> And with ASAN (-fsanitize=address) you get told more gory details, like
> that it's trying to do a 0x1_0000_0001-long read (4GiB plus 1 Byte… that
> read size is stable over the next couple extra ='s).
> I haven't deeply looked into this, from a cursory glance it might be
> (partly?) caused by the separator length being tracked in an `int`,
> which affects (in 5.4/git)
> llex.c:251: skip_sep (return, locvar on next line)
> llex.c:264: read_long_string (funarg)
> llex.c:447: llex (locvar)
> A quick test (int --> ptrdiff_t in those 4 places) _seems_ to fix it,
> but there might be more…
> -- Marco

I have had this sitting in my drafts for over a year, I think this is
the same bug?:

The overflow is in
Generate test file:

local f = assert("bug.lua", "w"))
local step = 1<<20
local eq = string.rep("=", step)
for i=1, 2<<31, step do