dump() not completing code list

@CrashingDutchman ... The ESP8266 is primarily designed to be a processor for WiFi based applications. In the ESP8266 everything runs on a "single thread" meaning that there is no real multi-tasking for applications. If an application "keeps control" for too long, then other areas of code are starved for attention. In the WiFi and networking world, such timings are critical. If the WiFi or networking code that is implemented inside the ESP8266 doesn't get control often enough, then it can break its contracts with other networking partners. In an attempt to detect this, the ESP8266 runs a periodic timer which causes a hardware interrupt to occur. This timer is apparently reset each time control is given to the necessary time sensitive portions of the ESP8266 code. If the timer fires, then it means that we haven't given control to the ESP8266 soon enough. The ESP8266 treats this as a problem and basically reboots itself in the hope that what ever was congesting access to the networking code will have "gone away".

In our story here, Espruino is itself the application running inside the ESP8266. Espruino then interprets your scripts to provide the model of running JavaScript. The internals of Espruino must give control back to ESP8266 networking often enough to satisfy its timing requirements.

Now ... imagine a complex function such as "dump()". What mr @tve is saying is that in his understanding, dump() is working through Espruino memory, building a text output and writing that as quickly as possible through the relatively slow serial output. This is a logic path within the Espruino implementation. If that logic path takes longer than maximum time we are allowed to spend outside of ESP8266 networking, the timer goes off and we abandon what we were doing. This timer is also known as the "watchdog timer".

I'm more than certain that there are gross inaccuracies in my description here and please forgive me for that ... but hopefully it supplies a bit of the background that might be useful to you. The bottom line though ... is it isn't your code that is the problem nor can you change anything in your JavaScript code to fix it ... unfortunately it is currently "just one of those things" in the current implementation of Espruino on the ESP8266.

Work is starting up to port Espruino to the new ESP32 devices ... which may alleviate this issue. The ESP32 is a dual core device where (typically) one core is dedicated to networking and the other core dedicated to the user application (Espruino in our story). This will simplify dramatically many of the technical obstacles. However, I would not anticipate a useful build of Espruino on ESP32 nor great availability of the devices until summer 2017 (it may be sooner, but I'd rather lower expectations than otherwise).