Multiple occurances during a trace() output request along with suggested fix

Sun 2020.05.03

'Do you have the actual code and steps to create the error'

Ask and ye shall receive . . .

The following is a challenge to @Gordon, @allObjects, @AkosLukacs, @MaBe, etal to reveal possible reasons for this anomaly before actually reading on, and no peeking with tools or accessing the console until some thought is given.   Game anyone?

When performing your individual test, it will be necessary to modify the code file to supply your known IP and p/w - Espruino WiFi required

Use the online WebIDE first, to also observe the corrupt console Window. Caveat, my tests are only on Windows10, so it could be that this is only related to MS. Same results with native .exe WebIDE.

https://www.espruino.com/ide/

Symptom: Performing a trace() loops indefinitely.

Do the following:

• Load code file codetinyMQTT20200503FORUM.js
• execute function c() in order to connect - wait five seconds for "connected!" response
• *(should the response not occur, don't continue as results will differ)*
• execute trace() and observe the endless loop

Why would the following code snippet cause the symptom above?

var server = "192.168.1.70";
//var server = "127.0.0.1";
//var server = "0.0.0.0";

var mqtt = require("tinyMQTT").create(server);
//mqtt.connect(); // Connects on default port of 1883

mqtt.on("connected", function(){
  console.log("connected");
});


var wifi = require("Wifi");

function c() {

wifi.connect("2WIRE", {password: "33212052"},
  function(err){
  if(err) {
    console.log(err);
  } else {
    mqtt.connect();
    console.log("connected!");
  }  
  });

}

Syntactically nothing. So before reading on, what might cause trace() to loop indefinitely?

No peeking - withdraw and ponder for an hour before continuing okay?

Okay, you peeked. Now, while I might concede that extra steps may/should be used by the end user/developer before final implementation, I took the examples right off the site tutorials and plugged away. Others might/will do the same.

What I discovered may/might also be the reason for my 400 JsVars of memory just evaporating (see rationale later), but won't be able to confirm until this is resolved.

Now, before peeking, I originally thought this to be specific to tinyMQTT as there is an outstanding GitHub issue #1583, but what is there, isn't related to the conditions here.

So, lets try just a basic http fetch, without MQTT

• Load code file codeWiFi20200503FORUM.js
• execute function c() in order to connect - wait five seconds for "connected!" response
• *(should the response not occur, don't continue as results will differ)*
• execute function g() to allow a get fetch of the resultant text file
• execute trace() and observe the endless loop

Before moving on to review of the output, realize that I have had intermittent issues for over two years, and I am pushing the memory limits of Espruino to be able to use the WebIDE console as an interactive interface for users. This means lots of console.log() statements, and the need for short function names to avoid having to type things like process.memory() out every two minutes.

To get around that I've been using a short function name for common commands. Stuff like s() for setup, r() for run, t() for test, v() for verify, w() for watch, p() for process.memory().

Now ask yourself what is the pattern here that would allow those to work, yet with the same practice, is now problematic?

Think about that before taking a peek at dump() and trace()

Now, the proper sequence to reveal needed detail as one will discover is to:

• reset(1)
• Load code file
• dump()
• trace()
• c()
• dump() - this is where the observant will gain the insight
• g()
• trace() - opt as will loop endlessly

So, figured it out? - surprising, isn't it!

Reviewing:

https://developer.mozilla.org/en-US/docs­/Web/JavaScript/Reference/Statements/var­

and specifically heading 'Initialization of several variables'

  var x = y = 1; // Declares x locally; declares y globally

confirms what I had observed a week ago.

View attached file 'wifi.connect.txt' for unminified detail

If one takes a peek at the .connect function() and yes, reverse minification is a real pain, even with online tools, I believe I've found the culprit, but wanted to provide the opportunity for others to discover also.

I've spent nearly a hundred hours testing and comparing just to identify what is happening and have 6Meg of data comprising of around three hundred dump and code files, should any of that be required. Why so long you ask? Well as the console either locks with a low memory situation or as in this case trace() causes an endless loop, it is not possible to get at the console to peek around. So, developing a technique ahead of time and comparing with a ton of data was the only way achievable. Now that I have discovered a repeatable situation, it is easy enough to build your own.

GitHub issue #1811 Anomaly in deployed module corrupts user namespace global scope #1811

Case revealed, but not solved.

Pardon me, back to a twelve year Rye I've been sippin' on . . . .

---

3 Attachments

• codetinyMQTT20200503FORUM.js
• codeWiFi20200503FORUM.js
• wifi.connect.txt