ESP8266 Community Forum

Hi,
runing the following code on ESP8266-01 using
NodeMCU 0.9.5 build 20150318 powered by Lua 5.1.4
a hard restart is the result:

function unescape (s)
s = string.gsub(s,"%%(%x%x)",function(h) return string.char(tonumber(h,16)) end)
return s
end
str = "abc%26def"
res = unescape(str)
print (res)

The hard restart happens a second after printing the result of abc&def.
There is no difference defining the variables "str" and/or "res" as local.

Something wrong with the routine?
Regards
KurtB

Moin,

I have 2 firmwares that only differ in LUAL_BUFFERSIZE

Using 4K: firmware crashes
Using 1K: firware does not crash

My interpretation:
The functions string.gsub and gsub.char seem to create an object ON THE STACK that
contains a buffer of above size. The functions are used nested and so add.
8K stack usages is a lot on an MCU. Maybe the stack and heap collide then (I don't know the memory model yet).

The increase in LUAL_BUFFERSIZE IMHO is an error and should be undone. If that breaks loading of compiled
lua code that needs to be fixed otherwise.
I would even think about lowering the buffer even further to
reduce stack pressure. 256 seems to be acceptable. (http://lua-users.org/lists/lua-l/2010-07/msg00640.html)
I don't understand the string handling enough for handling longer strings in lua e.g. for receive callbacks.

If there is enough interest in a prebuld version with 1k buf I could upload an image.

Carsten

Hi Carsten,

many thanks for your investigation.
Meanwhile I think it's related to the fact that the output string is shorter then the input string.
Please have a look to the function "unescape" where "%26" is replaced by "&". Means the output field is two bytes shorter then the input field. It seems to me the internal memory managment of LUA has some trouble with this.
What do you think?
Regards
Kurt

Nope,

lua is a script language here. It will care for basic stuff like this.
But the language interpreter itself is intertwined with nodemcu C code and esp8266 SDK code.
The calls from c into lua don't have any protection (lua_call versus lua_pcall) so any minor problem
in lua callback code will end in a panic with reboot.
Same when memory problems arise.
The lua language itself is IMHO very safe.


Carsten