ESP32: Possible scripter memory leak

[UBWH]

There seems to be a memory leak in V3.1.0 - I suspect in the SCRIPT code??? (EDIT: or maybe the Ethernet code ???)

In the above plot (over 7 days) - the main drops occur when I display the >w0, >w2, ... Web pages defined in my SCRIPT

I am at a loss to workout what to do next.

The MQTT messages are still flowing out - even with only 4kB of heap left (thats how I know how much heap is left - and can plot on OpenHAB)

But I can NOT login to the main web page. Browser just times out waiting for data.

EDIT: Browser timing out started when heap dropped below about 20 kB

Suggestions on how to fix this?

EDIT: Using WT32-ETH01, with 4 MB memory, and Ethernet port.

[Jason2866]

For finding the culprit it is necessary to rule out where to search. Use without Ethernet.
Since it happens when doing Display stuff, looks like a issue in scripter. Your code or the scripter implementation. Role back the scripter changes done to see if and which commit is causing.

[UBWH]

I have followed @Jason2866 's advice and stripped back almost 100% of my script and found a simple way to demonstrate the issue, which seems to have nothing to do with the dual network interfaces: just a SCRIPT problem.

SETUP:

• ESP32
• Tasmota V3.1.0, with USE_SCRIPT defined
• ETHERNET: OFF
• WIFI: ON

Test Process

Simply fetched the MAIN Tasmota page, with WGET. Used this bash script:

#!/bin/bash
for (( c=1; c<=200; c++ ))
do
   echo "$c times"
  wget  http://10.1.1.7/ -o /dev/null
  sleep 5
done

TEST 1 - SUCCESS

Zero drop of heap over 400 web gets of main Tasmota page.

SCRIPT

>D   

>U

>E

>S

>R

>J  

>T

TEST 2 - FAIL

Heap dropped form 97->48kB over 400 web gets of main page. (ran bash script twice)

= approx 0.12kB per web get
SCRIPT

>D   

>U

>E

>S

>R

>J  

>T

>w6 About

Here is the plot of the heap while the script ran twice.

I am on holidays and have no access to my Visual Studio to built a new Tasmota binary on the latest release to confirm this memory leak bug has not already been fixed.

Should I raise a new issue anyway?

[Jason2866]

No change the headline. Something like "Possible scripter memory leak" AND provide the script which causes the leak. There is a chance the script itself is to blame.

[UBWH]

Jason,

Headline updated.

Script(s)
I DID provide them. They are almost empty. See above

Adding >w6 About triggers the memory loss.

Would like to add

• during this testing never clicked the new About button on the main page. (But if I did, I assume it would display a blank page)

[Jason2866]

@gemu2015 Can you help?

[gemu2015]

ok, found the bug, will do pr in the next few days

[UBWH]

Have you made the PR yet?
I would like to patch my build and give it a test.

[gemu2015]

yes, done

[UBWH]

Thanks
:-)

[UBWH]

Fixed: See This PR: #20473

[mi-hol]

@UBWH We are hunting for root cause of reboot after~5 Min in #22833

Would you perhaps have a link to instructions "how to monitor free heap" as shown in your graph ?

[sfromis]

The general approach is that Tasmota is publishing STATE payloads via MQTT every TelePeriod, which among other fields has a value like "Heap":63. Those payloads can be subscribed to, stored, and presented by some backend tool, names like InfluxDB and Grafana comes to mind.

Of course, this type of monitoring is for longer time trends, not very useful for short time crashes. Using SetOption130 you can get Tasmota to include heap size in every console log message, which may work better as long as there is activity.

[mi-hol]

@sfromis actually using SetOption130 causes another issue on C6, see #22839