You are reading a single comment by @Gordon and its replies.
Click here to read the full conversation.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
@Gordon
Yes, when dumping, so as not to get in infinite loops, it only prints things once - so if it printed it above it'd add
...Sounds like an unlock as you say - IIRC the builtins are checked for by looking at
__proto__.constructorto see if it's a native function with a certain address, but the way__proto__links to#onconnectinstead looks broken.The fact it's actually all vaguely intact (vars pointing to other vars) looks like it's not actual corruption. It is probably just accidentally freeing something.
One thing that might help is to run
traceat several points during execution, and to diff it. It might show something?Do you have any kind of debugger? Sometimes when this kind of thing happens (if it's repeatable) I figure out what the variable number was, and then add a conditional breakpoint on
jsvFreePtr. If you can find where the assert is happening it might actually be right at the point where the variable that has the problem is being unlocked.The other option is @Kolban had spent some time making a windows-based test harness for the ESP8266 code. I'm not sure if it's working, but it is in the repo. If you can run that locally you might be able to reproduce the issue on a PC, and then you can debug it better?
Also, you can try editing
build_platform_config.pyand replacingRESIZABLE_JSVARSwith a fixed size of 1000. That'll force the Linux build to use 12 byte JsVars like the ESP8266, which might make it more likely that problems will occur?