How to debug random crash/reset ?

Hi all,
I started having this error lately on esp8266. It's not triggered by a particular line of code. My code is a bit large to be included here, it makes a data model and read from a sensor.
It looks like I am doing something that make the esp unstable, but the code continue running to some point where the esp is stressed then the crash happens. I tried another esp8266 board and with v1.94, no change. It's probably my code then. I would like to find the code part responsible for this instability. How to learn more about what happens ?

Any idea how to debug this problem ? is an abuse of callstack a possible cause ?

Polypod

 ets Jan  8 2013,rst cause:4, boot mode:(3,7)
wdt reset
load 0x40100000, len 2408, room 16
tail 8
chksum 0xe5
load 0x3ffe8000, len 776, room 0
tail 8
chksum 0x84
load 0x3ffe8310, len 632, room 0
tail 8
chksum 0xd8
csum 0xd8
2nd boot version : 1.6
  SPI Speed      : 80MHz
  SPI Mode       : QIO
  SPI Flash Size & Map: 32Mbit(512KB+512KB)
jump to run user1 @ 1000
rLoading 7436 bytes from flash...

Did you check the flags? E.getFlags() or something alike... that can help you. Since you know your code you may have an idea where it is heavy... so after certain buffer and move-around operations checking the flags can give you indication. Furthermore, try to break up code into setTimeout()s because that breaks the JavaScript thread an lets the ESP8266 do its things... there is anyway only a limited window that you can use before the Wifi tries to take over and crashes or takes over and JavaScript portion crashes. The single processor is just not the setup for doing much next to the Wifi job... not for nothing the ESP32 got launched which has the dual processor - one to deal with the Wifi/Bluetooth and one with the rest... Similar 'combination structures' I'm running successfully with Espruino Original and CC300, Pico with ESP8266, Espruino-Wifi. The money saved on the ESP8266 is just not worth your troubles...

From E.getFlags(), I only get : { "deepSleep": 0, "pretokenise": 0 }. is it supposed to return something else ?
I tried disabling wifi, with no change. You suggest combining 2 esp8266 with one only for wifi ? How do you connect them together ?

2 ESP8266 will not solve your problem, except you put a totally different binary on it that does ignore the Wifi... or you disable the Wifi (switch it off)... but it still will use you memory resources. Best is to get yourself a Pico.

Line 2 of your output is
wdt reset

This means the watchdog was triggered, due to the CPU being tried up - what have you got in a tight loop that ties up the CPU?

Ok, thanks,
Finally, the bug disappeared for good after removing this line and replacing with for loop : "var mp=tabarray.map(function(e) {print("upCr map",e); index++;print("index",index);e=jp(e); print("upCR map item "+index +" :",e);return e["name"]; })". Maybe map implementation has a problem, or the way I used it. I could not reproduce it in isolation, I still suspect of a call stack problem.
@Wilberforce, I realize that but, the problem is that the board does not freeze at a specific line but much later, like when I am reading the dht22 sensor.

@allObjects, what do you call 'combination structures' ? I thought the problem was the cpu not the memory. What is so good about the pico ?

@allObjects, Finally you was right. The bug came back, and went away when I used more setTimeOut as you suggested to break the function calls that pile too much. To me, it looks a lot like a lack of memory when piling too many local calls context. More than 10 in my case, i broke up in 5 and 5.

Lack of memory is probably less the issue... it is that ESP8266 has a watchdog that kicks in when in 'uninteruptable'/busy/'tied up'/in 'tight loop' (even though it is not really a loop) state for more than a set time. ESP8266 firmware can only take a break from serving the Wifi communication part for that set time to serve other things. I wonder now if one wire gets ESP8266 in such a tied up state... and you cannot break up the code into small enough pieces that this watchdog does not kick in.

So it is not directly

What is so good about the pico ?

It is that one processor takes care of the tying up things, such as talking 1-Wire, while the other one takes care of the high-maintenance drama queen called Wifi... And when both have some time in between their first/high priority tasks, they have a great time together - exchanging a few bytes over slow serial, which is interruptable and buffered... - they work in combination...