[ 5.4 work2 ] Stack overflow causes crash

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[ 5.4 work2 ] Stack overflow causes crash

actboy168@gmail.com

local function test()

    test()

end

test()

 

In lua compiled in msvc2017, this code will cause a crash.

 

--actboy168

 

Reply | Threaded
Open this post in threaded view
|

Re: [ 5.4 work2 ] Stack overflow causes crash

Jonathan Goble
On Mon, Dec 17, 2018 at 8:44 PM actboy168 <[hidden email]> wrote:

local function test()

    test()

end

test()

 

In lua compiled in msvc2017, this code will cause a crash.

 

--actboy168


When you say crash, do you mean other than a normal Lua error and traceback? An error and traceback is to be expected with this code since infinite recursion like this will eventually overflow the call stack. This is what I get on Linux, compiled with gcc:

$ lua
Lua 5.3.5  Copyright (C) 1994-2018 Lua.org, PUC-Rio
> do
>> local function test()
>> test()
>> end
>> test()
>> end
stdin:3: stack overflow
stack traceback:
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    ...
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in local 'test'
    stdin:5: in main chunk
    [C]: in ?

If that's what you're getting, then the behavior is correct. On the other hand, if you're getting a segmentation fault or some other strange non-Lua error, then I'm sure the Lua team would appreciate more details as to exactly what is occurring.
Reply | Threaded
Open this post in threaded view
|

Re: [ 5.4 work2 ] Stack overflow causes crash

Daurnimator
On Tue, 18 Dec 2018 at 13:40, Jonathan Goble <[hidden email]> wrote:
> This is what I get on Linux, compiled with gcc:
>
> $ lua
> Lua 5.3.5  Copyright (C) 1994-2018 Lua.org, PUC-Rio

Since https://github.com/lua/lua/commit/196c87c9cecfacf978f37de4ec69eba0a5971256
lua uses the C stack which *can* overflow.

Reply | Threaded
Open this post in threaded view
|

答复: [ 5.4 work2 ] Stack overflow causes crash

actboy168@gmail.com
In reply to this post by Jonathan Goble

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

 

--actboy168

 

发件人: [hidden email]
发送时间: 20181218 10:41
收件人: [hidden email]
主题: Re: [ 5.4 work2 ] Stack overflow causes crash

 

On Mon, Dec 17, 2018 at 8:44 PM actboy168 <[hidden email]> wrote:

local function test()

    test()

end

test()

 

In lua compiled in msvc2017, this code will cause a crash.

 

--actboy168

 

When you say crash, do you mean other than a normal Lua error and traceback? An error and traceback is to be expected with this code since infinite recursion like this will eventually overflow the call stack. This is what I get on Linux, compiled with gcc:

 

$ lua
Lua 5.3.5  Copyright (C) 1994-2018 Lua.org, PUC-Rio
> do
>> local function test()
>> test()
>> end
>> test()
>> end
stdin:3: stack overflow
stack traceback:
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    ...
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in local 'test'
    stdin:5: in main chunk
    [C]: in ?

 

If that's what you're getting, then the behavior is correct. On the other hand, if you're getting a segmentation fault or some other strange non-Lua error, then I'm sure the Lua team would appreciate more details as to exactly what is occurring.

 

Reply | Threaded
Open this post in threaded view
|

Re: [ 5.4 work2 ] Stack overflow causes crash

Xavier Wang


actboy168 <[hidden email]>于2018年12月18日 周二16:39写道:

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

 


You can try git HEAD on GitHub  and finding out that it has been fixed.

--actboy168

 

发件人: [hidden email]
发送时间: 20181218 10:41
收件人: [hidden email]
主题: Re: [ 5.4 work2 ] Stack overflow causes crash

 

On Mon, Dec 17, 2018 at 8:44 PM actboy168 <[hidden email]> wrote:

local function test()

    test()

end

test()

 

In lua compiled in msvc2017, this code will cause a crash.

 

--actboy168

 

When you say crash, do you mean other than a normal Lua error and traceback? An error and traceback is to be expected with this code since infinite recursion like this will eventually overflow the call stack. This is what I get on Linux, compiled with gcc:

 

$ lua
Lua 5.3.5  Copyright (C) 1994-2018 Lua.org, PUC-Rio
> do
>> local function test()
>> test()
>> end
>> test()
>> end
stdin:3: stack overflow
stack traceback:
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    ...
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in upvalue 'test'
    stdin:3: in local 'test'
    stdin:5: in main chunk
    [C]: in ?

 

If that's what you're getting, then the behavior is correct. On the other hand, if you're getting a segmentation fault or some other strange non-Lua error, then I'm sure the Lua team would appreciate more details as to exactly what is occurring.

 

--
regards,
Xavier Wang.
Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
In reply to this post by actboy168@gmail.com
> I am talking about lua5.4 work2. In fact it can't be reproduced on gcc or lua5.3.

Lua avoids stack overflows by counting the number of recursive calls
it makes. The constant LUAI_MAXCCALLS sets this limit, but it is hard
to find the "perfect" value for each system. Can you play with
this constant (either with -DLUAI_MAXCCALLS=<somevalue> or changing
its value in 'llimits.h' or anything equivalent) and tells us
which is the maximum value where the crash becomes a regular Lua
error?

Many thanks,

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

Viacheslav Usov
On Tue, Dec 18, 2018 at 6:21 PM Roberto Ierusalimschy <[hidden email]> wrote:

> Lua avoids stack overflows by counting the number of recursive callsit makes. The constant LUAI_MAXCCALLS sets this limit, but it is hard to find the "perfect" value for each system.

On many systems the Lua host can control the stack size of each thread it creates, so it might be rather small and indeterminate at the compile time. Even if the amount of the stack space used by Lua itself is carefully controlled, no such control (by Lua) is possible if C functions (of the host or third party libs) are called.

So I am afraid there is no way to avoid stack overflows without imposing some constraints on the execution environment, which may end up being quite arcane.

Cheers,
V.
Reply | Threaded
Open this post in threaded view
|

Re: [ 5.4 work2 ] Stack overflow causescrash

actboy168@gmail.com
In reply to this post by Roberto Ierusalimschy

I am using this version of github to test, and the results as follows

 

https://github.com/lua/lua/tree/af6d9f31165a13c34c0601f37ca5a67c365d1d01

 

msvc15.9/release/64bit LUAI_MAXCCALLS <= 1492

msvc15.9/release/32bit LUAI_MAXCCALLS <= 1698

 

--actboy168

 

发件人: [hidden email]
发送时间: 20181219 1:21
收件人: [hidden email]
主题: Re: 答复: [ 5.4 work2 ] Stack overflow causescrash

 

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

 

Lua avoids stack overflows by counting the number of recursive calls

it makes. The constant LUAI_MAXCCALLS sets this limit, but it is hard

to find the "perfect" value for each system. Can you play with

this constant (either with -DLUAI_MAXCCALLS=<somevalue> or changing

its value in 'llimits.h' or anything equivalent) and tells us

which is the maximum value where the crash becomes a regular Lua

error?

 

Many thanks,

 

-- Roberto

 

 

Reply | Threaded
Open this post in threaded view
|

Re: [ 5.4 work2 ] Stack overflow causescrash

Roberto Ierusalimschy
> I am using this version of github to test, and the results as follows
>
> https://github.com/lua/lua/tree/af6d9f31165a13c34c0601f37ca5a67c365d1d01
>
> msvc15.9/release/64bit LUAI_MAXCCALLS <= 1492
> msvc15.9/release/32bit LUAI_MAXCCALLS <= 1698

Thanks,

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

Andrew Gierth
In reply to this post by Roberto Ierusalimschy
>>>>> "Roberto" == Roberto Ierusalimschy <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
> 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. [...]

Lua has been using this system for many years, and it has been
doing quite well in embedded environments.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

Andrew Gierth
>>>>> "Roberto" == Roberto Ierusalimschy <[hidden email]> writes:

 >> 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. [...]

 Roberto> Lua has been using this system for many years, and it has been
 Roberto> doing quite well in embedded environments.

I wonder how many of them crash if you do

local function f(s) s:gsub(".", f) return "x" end f("foo")

and more to the point, how many of them will crash on that code if they
switch to 5.4 without realizing the default stack depth grew 10x.

--
Andrew.

Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
> I wonder how many of them crash if you do
>
> local function f(s) s:gsub(".", f) return "x" end f("foo")
>
> and more to the point, how many of them will crash on that code if they
> switch to 5.4 without realizing the default stack depth grew 10x.

Since you already have access to an official release of Lua 5.4, you
could send me a copy. It would save me a lot of work...

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

Egor Skriptunoff-2
In reply to this post by Andrew Gierth
On Wed, Dec 19, 2018 at 10:05 PM Andrew Gierth wrote:
 Roberto> Lua has been using this system for many years, and it has been
 Roberto> doing quite well in embedded environments.

I wonder how many of them crash if you do

local function f(s) s:gsub(".", f) return "x" end f("foo")

and more to the point, how many of them will crash on that code if they
switch to 5.4 without realizing the default stack depth grew 10x.

 
Instead of testing it in embedded environments, I've tested this one-line Lua program on usual desktop computer.
Here are the results.
 
On Linux
Lua built with gcc (32-bit and 64-bit executables):
 
Catchable error is raised:
   Lua 5.1(all)
   Lua 5.2(all)
   Lua 5.3(all)
   Lua 5.4_work2(32-bit)
 
Host application crashes:
   Lua 5.4_work2(64-bit)
 
 
 
On Windows
Lua built with different compilers:
VisualStudio2010 and MinGW (from MSYS2), both produce 32-bit and 64-bit executables:
 
Catchable error is raised:
   Lua 5.1(all)
   Lua 5.2(all)
   Lua 5.3(VS 32-bit, MinGW 32-bit, MinGW 64-bit)
 
Host application crashes:
   Lua 5.3(VS 64-bit)
   Lua 5.4_work2(all)
 
Reply | Threaded
Open this post in threaded view
|

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

Andrew Gierth
>>>>> "Egor" == Egor Skriptunoff <[hidden email]> writes:

 >> I wonder how many of them crash if you do
 >>
 >> local function f(s) s:gsub(".", f) return "x" end f("foo")
 >>
 >> and more to the point, how many of them will crash on that code if
 >> they switch to 5.4 without realizing the default stack depth grew
 >> 10x.

 Egor> Instead of testing it in embedded environments, I've tested this
 Egor> one-line Lua program on usual desktop computer.
 Egor> Here are the results.

 Egor> On *Linux*
 Egor> Lua built with gcc (32-bit and 64-bit executables):

 Egor> Catchable error is raised:
 Egor>    Lua 5.1(all)
 Egor>    Lua 5.2(all)
 Egor>    Lua 5.3(all)
 Egor>    Lua 5.4_work2(32-bit)

 Egor> Host application crashes:
 Egor>    Lua 5.4_work2(64-bit)

This suggests you're running with a stack size limit on the close order
of 16MB, perhaps? The default buffer size is based on sizeof(void*)
amongst other factors, so the 32-bit build is probably using about 12MB
of stack for that code and the 64-bit build around 20MB.

 Egor> On *Windows*
 Egor> Lua built with different compilers:
 Egor> VisualStudio2010 and MinGW (from MSYS2), both produce 32-bit and
 Egor> 64-bit executables:

 Egor> Catchable error is raised:
 Egor>    Lua 5.1(all)
 Egor>    Lua 5.2(all)
 Egor>    Lua 5.3(VS 32-bit, MinGW 32-bit, MinGW 64-bit)

 Egor> Host application crashes:
 Egor>    Lua 5.3(VS 64-bit)
 Egor>    Lua 5.4_work2(all)

I am no windows expert, but I believe the stack size limit of a windows
binary can be specified at link time. So I guess MinGW is using a
different default size (presumably 2MB or more) there, and that VS's
default stack size is on the order of 1MB to 1.5MB; Lua 5.3 uses
something like 1.8MB for that code on a 64-bit build, and something
around 1MB on a 32-bit build.

Incidentally, I tried making a list of functions with dangerous stack
usage. There appear to be three: string.gsub is the most obvious one,
since it explicitly invokes a function parameter while having a
luaL_Buffer on the stack, but there are at least two more that are more
subtle: table.concat and string.format can both invoke metamethods on
parameter values while having a luaL_Buffer on the stack.

I think this should work to demonstrate the problem for table.concat:

t = setmetatable({},
  {__index=function(t,i) local y = table.concat(t,'',1,1) end})
print(t[1])

Anyone think of any more functions that are vulnerable in this way?

--
Andrew.

Reply | Threaded
Open this post in threaded view
|

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

Andrew Gierth
>>>>> "Andrew" == Andrew Gierth <[hidden email]> writes:

 Egor> Lua 5.4_work2(32-bit)

 Egor> Host application crashes:
 Egor> Lua 5.4_work2(64-bit)

 Andrew> This suggests you're running with a stack size limit on the
 Andrew> close order of 16MB, perhaps? The default buffer size is based
 Andrew> on sizeof(void*) amongst other factors, so the 32-bit build is
 Andrew> probably using about 12MB of stack for that code and the 64-bit
 Andrew> build around 20MB.

My estimates were a bit off, I think I forgot to count increments of the
C call depth by the interpreter (i.e. each recursion through gsub is
presumably incrementing the call depth twice for each buffer on the
stack, not once).

Using the code currently at github.com/lua/lua master branch, and
instrumenting the stack depth error to actually report the measured
depth, here's some actual numbers I get. The test cases are:

"lua" : local function f() f() return 1 end f()
"gsub": local function f(s) s:gsub(".", f) return "x" end f("foo")
"conc": print(setmetatable({},{__index=function(t,i) table.concat(t,"",1,1) end})[1])
"fmt" : print(setmetatable({},{__tostring=function(t) string.format("%s",t) end}))

freebsd, clang 3.9.1, -O2, 64-bit:

lua:  C stack overflow at call depth 2200, stack 317505 bytes
gsub: C stack overflow at call depth 2200, stack 10120449 bytes
conc: C stack overflow at call depth 2200, stack 9540737 bytes
fmt:  C stack overflow at call depth 2200, stack 9585121 bytes

freebsd, clang 3.9.1, -O2, 32-bit:

lua:  C stack overflow at call depth 2200, stack 2005217 bytes (!)
gsub: C stack overflow at call depth 2200, stack 6045857 bytes
conc: C stack overflow at call depth 2200, stack 5817553 bytes
fmt:  C stack overflow at call depth 2200, stack 5812481 bytes

freebsd, clang 3.9.1, -O0, 64-bit:

lua:  C stack overflow at call depth 2200, stack 7000037 bytes
gsub: C stack overflow at call depth 2200, stack 13728581 bytes
conc: C stack overflow at call depth 2200, stack 13342341 bytes
fmt:  C stack overflow at call depth 2200, stack 13366037 bytes

freebsd, clang 3.9.1, -O0, 32-bit:

lua:  C stack overflow at call depth 2200, stack 6718493 bytes
gsub: C stack overflow at call depth 2200, stack 8765165 bytes
conc: C stack overflow at call depth 2200, stack 8633597 bytes
fmt:  C stack overflow at call depth 2200, stack 8670309 bytes

freebsd, gcc8, -O2, 64-bit:

lua:  C stack overflow at call depth 2200, stack 528425 bytes
gsub: C stack overflow at call depth 2200, stack 10225961 bytes
conc: C stack overflow at call depth 2200, stack 9593545 bytes
fmt:  C stack overflow at call depth 2200, stack 9690505 bytes

freebsd, gcc6, -O2, 64-bit:

lua:  C stack overflow at call depth 2200, stack 528409 bytes
gsub: C stack overflow at call depth 2200, stack 10208377 bytes
conc: C stack overflow at call depth 2200, stack 9593529 bytes
fmt:  C stack overflow at call depth 2200, stack 9690489 bytes

freebsd, clang 6.0.1, -O2, 64-bit:

lua:  C stack overflow at call depth 2200, stack 422977 bytes
gsub: C stack overflow at call depth 2200, stack 10173217 bytes
conc: C stack overflow at call depth 2200, stack 9540801 bytes
fmt:  C stack overflow at call depth 2200, stack 9690545 bytes

freebsd, clang 6.0.1, -O2, 32-bit:

lua:  C stack overflow at call depth 2200, stack 2110725 bytes
gsub: C stack overflow at call depth 2200, stack 6098661 bytes
conc: C stack overflow at call depth 2200, stack 5852789 bytes
fmt:  C stack overflow at call depth 2200, stack 5900389 bytes

(I'm not set up to do 32-bit tests with gcc)

Those are bigger differences than I expected for both 32-bit vs 64-bit,
and for clang39 vs clang60 vs gcc.

--
Andrew.

Reply | Threaded
Open this post in threaded view
|

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

Egor Skriptunoff-2
In reply to this post by Andrew Gierth
On Fri, Dec 21, 2018 at 5:24 AM Andrew Gierth wrote:
 >> local function f(s) s:gsub(".", f) return "x" end f("foo")

 Egor> On *Linux*

 Egor> Catchable error is raised:
 Egor>    Lua 5.1(all)
 Egor>    Lua 5.2(all)
 Egor>    Lua 5.3(all)
 Egor>    Lua 5.4_work2(32-bit)

 Egor> Host application crashes:
 Egor>    Lua 5.4_work2(64-bit)

This suggests you're running with a stack size limit on the close order
of 16MB, perhaps?

No.
On all my Linux machines "ulimit -s" prints "8192"

 
 Egor> On *Windows*

 Egor> Catchable error is raised:
 Egor>    Lua 5.1(all)
 Egor>    Lua 5.2(all)
 Egor>    Lua 5.3(VS 32-bit, MinGW 32-bit, MinGW 64-bit)

 Egor> Host application crashes:
 Egor>    Lua 5.3(VS 64-bit)
 Egor>    Lua 5.4_work2(all)

I am no windows expert, but I believe the stack size limit of a windows
binary can be specified at link time. So I guess MinGW is using a
different default size (presumably 2MB or more) there, and that VS's
default stack size is on the order of 1MB to 1.5MB; Lua 5.3 uses
something like 1.8MB for that code on a 64-bit build, and something
around 1MB on a 32-bit build.

You are correct.
On Windows every .EXE file has each own stack size (this value is stored in the file header).
Default stack size in applications created with VisualStudio2010 is 1 MByte, with MinGW - 2 MBytes.
So, under VS, linker option "/STACK:8388608" solves the problem for Lua 5.3.
For Lua 5.4.0-work2, stack size of 8 MBytes is not enough, but 16 is OK.
 

Roberto, what stack size does Lua 5.3+ VM expect?
This information is essential for correct building Lua on Windows.
Reply | Threaded
Open this post in threaded view
|

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

Andrew Gierth
>>>>> "Egor" == Egor Skriptunoff <[hidden email]> writes:

 >> This suggests you're running with a stack size limit on the close
 >> order of 16MB, perhaps?

 Egor> No.
 Egor> On all my Linux machines "ulimit -s" prints "8192"

Right, so 8MB. As I said in the other message, I overestimated the 5.4
stack usage for that recursive gsub by 2x due to not accounting for the
depth being incremented twice for each recursion, not once.

But that of course leads to the question: is there a way to make 5.4
recurse such that there's a buffer on the stack for each C call level?
And it turns out that yes, there is:

print(setmetatable({},{__index=table.concat, __len=function() return 1 end})[""])

C stack overflow at call depth 2200, stack 18772305 bytes

I think that's probably the largest stack depth possible with the
default compile options and no modules.

--
Andrew.

Reply | Threaded
Open this post in threaded view
|

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

Viacheslav Usov
In reply to this post by Egor Skriptunoff-2
On Fri, Dec 21, 2018 at 7:38 PM Egor Skriptunoff <[hidden email]> wrote:
 
Roberto, what stack size does Lua 5.3+ VM expect?
This information is essential for correct building Lua on Windows.

The question does not make much sense.

A thread's stack size is generally not a compile time constant on Windows. 

In a typical application, the Lua VM is not the only and potentially not even a major user of stack.

Finally, the use of stack solely by the Lua VM is highly application-specific.

Cheers,
V.
 
Reply | Threaded
Open this post in threaded view
|

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

Egor Skriptunoff-2
On Sat, Dec 22, 2018 at 12:39 PM Viacheslav Usov wrote:
 
Roberto, what stack size does Lua 5.3+ VM expect?
This information is essential for correct building Lua on Windows.

The question does not make much sense.

Does a question about VM crash make sense?

 
A thread's stack size is generally not a compile time constant on Windows. 

The stack size must be known at link time on Windows.

 
In a typical application, the Lua VM is not the only and potentially not even a major user of stack.

Yes, of course, a host application developer should take into consideration both
"how much stack Lua VM needs" and "how much stack the application itself needs"


Finally, the use of stack solely by the Lua VM is highly application-specific.

Of course, stack usage of Lua VM depends on the application-specific Lua scripts.
I believed that Lua VM does guarantee to never crash the host application whatever Lua script is given.
We all do know that "Lua is portable"; but it appears that on some OS the default stack size (1MByte is quite sane value) might be not enough for Lua VM.
This problem would be easy-to-fix if we knew how much stack could Lua VM eat.
So, the question about guaranteed maximum of stack usage does make sense.


12