Re: 答复: [ 5.4 work2 ] Stack overflow causes crash

[Andrew Gierth <andrew@...>]

>>>>> "Roberto" == Roberto Ierusalimschy <roberto@inf.puc-rio.br> writes:

 >> I am talking about lua5.4 work2. In fact it can't be reproduced on gcc or lua5.3.

 Roberto> Lua avoids stack overflows by counting the number of recursive
 Roberto> calls it makes.

OK, so this is another big problem for embedded environments: there is
no reasonable way for a single compile-time recursion count limit to be
able to limit the C stack depth adequately. One level of recursion in
the VM is probably only a few dozen bytes, but recursion through any
function that has a lua_Buffer (looking at you string.gsub) eats more
than 8KB on a 64-bit build. Going 2200 calls deep on that means more
than 18MB of stack space, which while it may be no big deal for the main
thread of a Unix process, is going to be a serious issue in other cases.

Forcing the environment to mess with the compile-time constants to get
safe values then makes it effectively impossible to use a shared
liblua.so, or even a package-installed liblua.a, and everything has to
compile its own interpreter or risk crashing. There isn't even any way
for the environment to determine what value of LUAI_MAXCCALLS the
interpreter was compiled with, other than by trial and error (which
could be dangerous in itself).

One possible solution would be for the interpreter to provide the option
of a C stack check hook that could be supplied by the environment; it
could be called every, say, 16 levels of nesting without too much
overhead, and have it return a true/false flag for whether to proceed or
fail with an error.

-- 
Andrew.