[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Bug : sieve.lua
- From: Michael Broughton <mbobowik@...>
- Date: Mon, 31 Jul 2006 11:57:52 -0600
This is a problem with coroutine recursion. Check out this thread:
My embedded setup uses Lua and uClinux on a nommu ColdFire. After
discovering this problem myself, I decided to remove the coroutine lib
from my build and I have not had any other problems with Lua. None quite
so nasty, anyway.
Also, the above link has a version of 'sieve.lua' that does not use
coroutines. It runs successfully on my system, even with a large N. I
think it's faster too.
Archie Maskill wrote:
Hello there -
There appears to be a problem when running 'sieve.lua', the test
script that comes with the Lua source code.
I'm running it under uClinux on an embedded device with an ARM
processor and no MMU.
The script prints all prime numbers up to 1000, and consistently gets
as far as "359" before crashing with a SIGSEGV. The script does run
for longer when I increase the lua executable's stack size using the
uClinux tool 'flthdr'. I increased it from 32768 to 65536, and it
consistently reached the prime "787" before segfaulting.
Changing the constants "LUAI_MAXCALLS" and "LUAI_MAXCSTACK" to much
smaller values in 'luaconf.h' and recompiling does not appear to make
any difference to where the program segfaults.
If the crash is caused by excessive recursion, we'd hope that Lua's
checks against MAXCALLS and MAXCSTACK would cause the program to exit
cleanly (i.e. not segfaulting). As it doesn't do this, even with very
small values of MAXCALLS and MAXCSTACK, we suspect the fault has
something to do with "coroutine" which is used many times in
1) is this a known bug? Is it a problem in coroutine, not checking
against stack size limits somehow?
2) are we right to expect that Lua would exit cleanly (i.e. with an
error message, not a segfault) with normal recursion reaching the
limits MAXCALLS and MAXCSTACK?
3) are there some parameters we can set, or is there a safe stack size
we can give the program when it runs where we can be sure a script
won't overrun the stack?
By the way, a segfault is particularly bad on an embedded system with
no MMU because it indicates random memory, possibly belonging to
another process, is being overwritten.