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

[Andrew Gierth <andrew@...>]

>>>>> "Egor" == Egor Skriptunoff <egor.skriptunoff@gmail.com> writes:

 >> Even that is impossible if the host provides functions using varying
 >> amounts of stack size callable from Lua, and the user is free to
 >> supply Lua code, even assuming that Lua can safely predict and
 >> control its own stack usage.

 Egor> Nothing prevents you from checking stack size in your own
 Egor> application (and raise an error if the next operation might use
 Egor> more stack space than you have available).

Well, the problem (at least for me) is that I _can't_ check stack usage
within the 5.4-work VM, since it can go deeper than my available stack
space while never calling any non-Lua function. I would have to assume
that any call into Lua might take 7MB of stack (or 2MB if I can
guarantee that Lua was compiled with optimization, which I can't) -
which is a problem because I can't guarantee to have more than 2MB of
stack at all, and even by having the admin change configuration settings
I may not be able to get more than 3.5MB available on Windows without
forcing the user to compile their own binaries. (And that's WITHOUT
counting the stack usage of gsub/concat/format which adds additional
megabytes of usage; I could if necessary at least intercept all of those
functions and check stack depth on each call.)

Testing on a stack-instrumented 5.3.5 suggests that I can't get more
than ~520kB deep on the stack without using gsub/concat/format, and even
that much requires both pcall and -O0; without pcall I can't get more
than about 200kB deep. 200kB is well within my allowed 512kB safety
margin, so if I were to intercept string.gsub, string.format and
table.concat (in addition to pcall which I already do) and add stack
depth checks to those, I wouldn't need any other checks.

-- 
Andrew.