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

Thr 2020.04.30

'that small section of trace output isn't enough to get any useful information'

I was also under the same assumption as I attempted to get at the culprit from the console. As I explained while using the online IDE, that browser tab instance became corrupt, not allowing easy drag through (similar to Ctrl+A) forcing me to attempt to stitch what I could back together. Felt that the observation of endless while trap was more important, and provided the best I could to get at least something documented.

'Do you have the actual code and steps'

Pretty much spelled that out in the last line of the post. I'm fearful of just providing what I 'knew' at the time as I'll guess you'll want to 'know', that burning desire to get at it right now, will start down a path of no such luck, when focussing on Bangle is where your skills are currently needed. But to placate you for a bit, the first link in post #1 points to the code block I started with. Under a hunch to initially find out if the templated string issue had been merged into the online IDE, as I also wanted to test some templated code, I loaded that up instead of the native .exe WebIDE, also knowing that the native IDE will eventually be replaced, so wanted to compare their also.

What I was in the process of doing, was to upload that code block from a file that I had been editing in notepad++ as I have done for all projects. I then cut-n-paste working code snippets into the console side, which 99% of the time don't require editing, as they have worked in other projects. I had been using dump() and trace() to copy to a file for ease of review in notepad++ as I saw an anomaly within dump(). In my haste, as I knew trace() would be needed, I bypassed grabbing the dump() on it's own. To my surprise, when I ran trace(), the output was just updating as slow as a BLE upload might look, so I walked away for a bit. Came back and it was still updating, even though there were only a hundred lines or so of code. As I had a fair amount of experience using trace(), knew that couln't be the case so attempted to grab what I could, but mouse highlighting wouldn't allow a similar Ctrl+A grab. The rest is outlined in the initial post.

As what I really needed were the steps and snippets, what I had entered initially but as indicated had scrolled North, so the actual steps are gone, but I had pencil'd a few notes and as I pointed out in the last line, will make a vain attempt.

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 . . . .