[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Bug: long strings with REALLY long delimiters…
- From: Daurnimator <quae@...>
- Date: Wed, 12 Dec 2018 15:08:13 -0800
On Wed, 12 Dec 2018 at 13:55, nobody <email@example.com> 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.."]"
> 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 https://www.lua.org/source/5.3/llex.c.html#skip_sep
Generate test file:
local f = assert(io.open("bug.lua", "w"))
local step = 1<<20
local eq = string.rep("=", step)
for i=1, 2<<31, step do