ESP32 memory leaks WIFI and MQTT

Thr 2019.10.17

'Not sure what you want me to console.log()'

Examples at:

https://www.w3schools.com/js/js_output.a­sp
http://www.espruino.com/Reference#l_cons­ole_log

from #10 'On a S.W.AG. hunch, try console.log() the value of 'iwico''

console.log( iwico );

Thank you @dwinfiel for the postings. This will assist others should we not locate the offending binary culprit. While I'm primarily a supporter of official supported boards, I don't have access to an ESP32 to test your code. However, we still have a bit more to do to gather sufficient information to both rule out what isn't the cause and hopefully locate what is going on.

Based on your postings, my first impression is that although you have diagnosed down to the connect/disconnect event and have observed memory decrease, I don't believe this is a result of the internal workings of Espruino.

Possibility 1

ref L8 in listing 3 of post #8

It might be that clearInterval(iwico); is being passed a bad handle, an error is being thrown and not detected. (by we humans) One way to test this would be to place that line within a try/catch block and also monitor L9 in post #11 . L9 seems to indicate unused timers lying around, maybe not getting cleared correctly, or getting stepped on and a new one created, bumping up the handle count. If that value grows, would be a good indicator we are on the right track.

It is indicated in post #1 that Javascript is new to you, so forgive me if this is too basic;

https://www.w3schools.com/js/js_errors.a­sp

replace line 8 with the following:

try {
  console.log( "calling clear interval + [" + iwico + "]" );
  clearInterval(iwico);
} catch( e ) {
  console.log( "Err at line xx " + e.message );
  console.log( process.memory().free );
}

Possibility 2

L28 is getting called, while a timeout is still being processed, also not freeing up memory.

https://www.w3schools.com/js/js_timing.a­sp

Use the same technique above to monitor the handle returned from that function. Also note that to clear a running one needs clearTimeout() which is subtly different from clearInterval(). The w3schools website has "TryIt" pages to speed understanding.

Possibility 3

Lines like #7 console.log('Wifi disconnected'); within the WiFi core functions are causing unique new strings on each invocation. This would gobble up memory. As a test, comment out those lines, one at a time-and-test, then the next one, and so on, then also monitor :free

One way around that would be to define the string once outside the function, then pass the variable name to the console.log() function, rather than a new string each invocation.

Possibility 4

'Would trying an older version help?'

It would be a good comparison test, but we are not there yet. Too time consuming to flash, with most likely no additional troubleshooting detail.

The above should provide sufficient detail to narrow this down.