ESP8266 Community Forum

- Wed Apr 01, 2015 3:56 pm #13223 Hi Carsten,
do be honest, I cannot say which part of the code could be the reason for reboot / crash.
I made the observation, only.
Do you have an idea how to program such an unescape routine other then mine? I found my one (of someone else) in the www. Interesting thing, I tested the "unescape" routine with LUA on windows 8.1 without any problem. From this, I assume the reason must be anywhere in the implementation of LUA at ESP8266 or somewhere deeper in the code. I see no chance for fixing by myself.
Regards
Kurt

- Wed Apr 01, 2015 5:06 pm #13226 Moin Kurt,

sorry if I wasn't clear enough. Your code is fully OK and doing things like that should not
result in a restart.
When compiling the firmware the buffersize parameter is set to high for the small esp8266 when doing
lua string operations.
Thats why your firmware crashes.
It is not easy to make the lua language environment stable on a small environment.
Dealing with error conditions due to lack of resources like memory in certain operations
is difficult.
Errors can corrupt the internal data structure and will result in crashes.
That is what you see here.
The lua language will protect you from low level problems but its environment needs some bug fixes.
Until then we have to live with crashes and reboots.
I built the same firmware using a smaller value for the buffersize (1024 bytes instead of 4096 bytes)
which makes the operations of your example need less memory resources internally.
This is why your example program does not crash my esp using my version of the firmware.
The firmware contains the lua interpreter that translates your program into low level function calls and
it just uses less memory for executing e.g. the gsub function and so avoids exhausting memory.

Hope that helps,
Carsten

You can try to avoid some operations to

Hi Carsten,
do be honest, I cannot say which part of the code could be the reason for reboot / crash.
I made the observation, only.
Do you have an idea how to program such an unescape routine other then mine? I found my one (of someone else) in the www. Interesting thing, I tested the "unescape" routine with LUA on windows 8.1 without any problem. From this, I assume the reason must be anywhere in the implementation of LUA at ESP8266 or somewhere deeper in the code. I see no chance for fixing by myself.
Regards
Kurt

Get your modules here:

https://www.banggood.com/custlink/KvGGhGF4wG

- Thu Apr 02, 2015 7:17 am #13261 @cal
I'm facing a similar issue with an attempted oled library and wondering if you can throw some light on how to do this? What / Where to edit the buffersize?

I built the same firmware using a smaller value for the buffersize (1024 bytes instead of 4096 bytes)

All help is appreciated.

- Thu Apr 02, 2015 9:34 am #13276 Moin,

change as follows:

app/lua/luaconf.h
@@ -542,8 +542,16 @@ extern int readline4lua(const char *prompt, char *buffer, int length);
/*
@@ LUAL_BUFFERSIZE is the buffer size used by the lauxlib buffer system.
*/
+/*#define LUAL_BUFFERSIZE ((BUFSIZ)*4) */
#define LUAL_BUFFERSIZE BUFSIZ

The increase was done in nodemcu patch to solve problems loading compiled lua programs > 1 K.
I didn't checked if reducing buffersize will re-introduce that bug. If so a simple fix
would be changing the single usage in the bytecode loading code to (4*(LUAL_BUFFERSIZE)).
I am willing to help if that problem arises. From my very short look at the bytecode loading code
I am not convinced that stack based memory is a good solution there.
I am trying to make my esp8266 with nodemcu more robust in case of short resources or at minimum provide
better error messages/stack traces before doing a reboot.

Maybe someone can give me a hint about the RAM memory model used when running nodemcu.
The typical setup is having a RAM block where C stack starts at one end e.g. lower end and heap memory (malloc etc.)
start at the other end.
Is that true with nodemcu, too.
I think this is the case and there is no protection or detection in place when both start to overlap other than
memory corruption and typically a reboot soon.

Any hints where to look for more infos?





Carsten

@cal
I'm facing a similar issue with an attempted oled library and wondering if you can throw some light on how to do this? What / Where to edit the buffersize?

I built the same firmware using a smaller value for the buffersize (1024 bytes instead of 4096 bytes)

All help is appreciated.

Get your modules here:

https://www.banggood.com/custlink/KvGGhGF4wG