Too many levels of nested functions causes a reset

[Ezekiel-DA]

Hi,

I'm not sure if this is fixable or simply a memory limitation (I assume the interpreter is running out of heap at some point) but I figured this was worth sharing since it took me a long time to track down this issue in a real program.

This appears to be a regression between master and dev / dev096 btw, the level of nesting I was using in my real code still works if I flash back to the master branch.

Here is a silly test case to show the issue:

local test = function()
    local t = function()
        return function()
            return function()
                return function()
                    return function()
                        return nil
                    end
                end
            end
        end
    end
end

test()

trying to execute this (or even trying to node.compile() it) will cause a reboot. Removing a level of nesting makes the issue disappear.

[iMarvinS]

That is a very massive "callback hell".
You should better use this solution (https://github.com/tuanpmt/lua-async).

[marcoskirsch]

Yeah, it seems like you're running out of memory. Try your experiment again but this time print out the nesting level and the heap at each step. It should be pretty obvious then.

I've been frustrated at how little memory there is for Lua scripts myself.

[nodemcu]

NodeMCU 0.9.5 build 20150214  powered by Lua 5.1.4
lua: cannot open init.lua
> local test = function()
>>     local t = function()
>>         return function()
>>             return function()
>>                 return function()
>>                     return function()
>>                         return nil
>>                     end
>>                 end
>>             end
>>         end
>>     end
>> end
>
> test()
stdin:1: attempt to call global 'test' (a nil value)
>

my result
what's your version.
mine is build from dev branch.

[dvv]

local doesnt work as expected in REPL. try test = function() ...

[nodemcu]

> test = function()
>>     local t = function()
>>         return function()
>>             return function()
>>                 return function()
>>                     return function()
>>                         return nil
>>                     end
>>                 end
>>             end
>>         end
>>     end
>> end
>
> test()
>
> =node.heap()
21152
>

[dvv]

test()()()()()(), no?

[nodemcu]

> =node.heap()
21152
> test()()()()()()
stdin:1: attempt to call a nil value
>

......

[jorgempy]

test()()()()()() wont work, you're not returning the "local t" function

[szakharchenko]

I can't believe the device is sow low on memory we can't afford 5 nested functions. Indeed,

function x(a1)
    return function(a2)
        return function(a3)
            return function(a4)
                return function(a5)
                    return a1+a2+a3+a4+a5
                end
            end
        end
    end
end
print(x(1)(2)(3)(4)(5))

This code, when loaded, prints 15 (correctly), proving that compilation, and execution, succeeds, but NodeMCU restarts a second or so after. The actual issue is some bug in the compiler (node.compile() fails similarily). This might be a memory management issue, but I don't think it's a memory outage.
If you compile it with node.compile(), the output file is generated and is not broken; you can run it and it'll work fine.

[szakharchenko]

JFYI, the problem doesn't appear (at least on 5 nesting levels;) ) on current dev096 firmware:

NodeMCU custom build by frightanic.com
    branch: dev096
    commit: e4f79508e1d086a46f90bdf3b9b450e13c3aa015
    SSL: false
    modules: node,file,gpio,wifi,net,pwm,tmr,adc,uart
    built on: 2015-09-15 07:55
 powered by Lua 5.1.4

[TerryE]

@szakharchenko, These are known constraints of running a Lua RTS on a chip with 40kB working RAM whee a chunk is taken up by the firmware. Compiling is very malloc/free hungry and fragments the memory pool. Avoiding compilation in general results in more usable memory; again a known characteristic. Sorry but this isn't an issue in the sense of something that we can identify a specific fix for.