esp8266 / Arduino

ESP8266 core for Arduino
GNU Lesser General Public License v2.1
15.99k stars 13.34k forks source link

memory leak 184 bytes at a time #1923

Closed yomasa closed 8 years ago

yomasa commented 8 years ago

Basic Infos

looks like 184 bytes get lost every time you post to the page ie :'http://192.168.0.6/gpio/1'

Hardware

Hardware: ESP-12, wemos mini, esp-7 Core Version: 2.2.0-rc1

memory leak?

using the example sketch WifiWebServer added one line of code at the end of sketch

Serial.println( ESP.getFreeHeap(),DEC);

Settings in IDE

Module: wemos mini Flash Size: ?4MB/1MB? CPU Frequency: ?80Mhz? Flash Mode: ?qio? Flash Frequency: ?40Mhz? Upload Using: ?OTA / SERIAL? Reset Method: ?ck / nodemcu?

Sketch

/*

const char* ssid = "your-ssid"; const char* password = "your-password";

// Create an instance of the server // specify the port to listen on as an argument WiFiServer server(80);

void setup() { Serial.begin(115200); delay(10);

// prepare GPIO2 pinMode(2, OUTPUT); digitalWrite(2, 0);

// Connect to WiFi network Serial.println(); Serial.println(); Serial.print("Connecting to "); Serial.println(ssid);

WiFi.begin(ssid, password);

while (WiFi.status() != WL_CONNECTED) { delay(500); Serial.print("."); } Serial.println(""); Serial.println("WiFi connected");

// Start the server server.begin(); Serial.println("Server started");

// Print the IP address Serial.println(WiFi.localIP()); }

void loop() { // Check if a client has connected WiFiClient client = server.available(); if (!client) { return; }

// Wait until the client sends some data Serial.println("new client"); while(!client.available()){ delay(1); }

// Read the first line of the request String req = client.readStringUntil('\r'); Serial.println(req); client.flush();

// Match the request int val; if (req.indexOf("/gpio/0") != -1) val = 0; else if (req.indexOf("/gpio/1") != -1) val = 1; else { Serial.println("invalid request"); client.stop(); return; }

// Set GPIO2 according to the request digitalWrite(2, val);

client.flush();

// Prepare the response String s = "HTTP/1.1 200 OK\r\nContent-Type: text/html\r\n\r\n<!DOCTYPE HTML>\r\n\r\nGPIO is now "; s += (val)?"high":"low"; s += "\n";

// Send the response to the client client.print(s); delay(1); Serial.println("Client disonnected");

// The client will actually be disconnected // when the function returns and 'client' object is detroyed

Serial.println( ESP.getFreeHeap(),DEC);

}

igrr commented 8 years ago

This memory should be reclaimed after a couple of minutes, once TCP connection exists TIME_WAIT state. Are you sure that free heap doesn't return to the original value after a few minutes?

gpepe commented 8 years ago

not leek, but 20k eating this code:

`

include

include

WiFiServer server(80);

const char* ssid = "???"; const char* password = "???";

static const char eatHeap[] =
"HTTP/1.1 200 OK\r\nContent-Type: text/html\r\n\r\n<!DOCTYPE HTML>" \ "\r\n";

size_t orig;

void setup() { WiFi.begin(ssid, password); server.begin(); orig = ESP.getFreeHeap(); }

void loop() { WiFiClient client = server.available(); if (client) { String s; s += eatHeap; s += orig; s += "/"; s += ESP.getFreeHeap(); s += ""; client.print(s); client.flush(); client.stop(); } }

`

gpepe commented 8 years ago

and f5 key down esp die :))

gpepe commented 8 years ago

edit tcp.c and recompile lwip to stop heap eating:

/* Check if this PCB has stayed long enough in TIME-WAIT / if ((u32_t)(tcp_ticks - pcb->tmr) > 10) { // if ((u32_t)(tcp_ticks - pcb->tmr) > 2 \ TCP_MSL / TCP_SLOW_INTERVAL) { ++pcb_remove; }

F5 never die :))

igrr commented 8 years ago

ESP8266WebServer library handles this stuff for you, without breaking TCP protocol spec.

rafichris commented 8 years ago

so this isn't a memory leak issue it is just performing according the tcp spec? In my case I use ajax to do some interaction between user and the server every second. Is there an elegant way to prevent memory is running out?

hmiez commented 7 years ago

I am a little bit confused about the wifi client heap issue.

I checked: 184 heap bytes are really lost each time we receive a request (this formerly produced a hangup in my application), BUT leaks are sometimes retreived after a while (a while = several minutes). See below the result of a modified WiFiWebServer, with timings. We can see that after 3 mins (187s) we have the same heap that after 11s.

If the number of client requests is somewhat high, any app will quickly run in troubles.

Even when the client is destroyed in the app (local client variable after the function has returned) or if the client is stopped (client.stop()) the TCP connection should be closed. But, in my tests, no memory is returned !!

Does anyone has an idea how to proceed to leave a clean situation without waiting for minutes ?

(my configuration: Arduino IDE 1.8.1 / esp8266 SDK 2.3.0 as mentionned in the arduino menu)

Connecting to xxx...... connected Server started @ 192.168.1.13 time : 6s received: GET /gpio/0 HTTP/1.1 heap is now: 45056 time : 6s received: GET /favicon.ico HTTP/1.1 heap is now: 44872 time : 10s received: GET /gpio/0 HTTP/1.1 heap is now: 44688 time : 10s received: GET /favicon.ico HTTP/1.1 heap is now: 44504 time : 11s received: GET /gpio/0 HTTP/1.1 heap is now: 44320 time : 12s received: GET /favicon.ico HTTP/1.1 heap is now: 44136 time : 12s received: GET /gpio/0 HTTP/1.1 heap is now: 43952 time : 12s received: GET /favicon.ico HTTP/1.1 heap is now: 43768 time : 44s received: GET /gpio/0 HTTP/1.1 heap is now: 43584 time : 44s received: GET /favicon.ico HTTP/1.1 heap is now: 43400 time : 81s received: GET /gpio/0 HTTP/1.1 heap is now: 43216 time : 81s received: GET /favicon.ico HTTP/1.1 heap is now: 43032 time : 111s received: GET /gpio/0 HTTP/1.1 heap is now: 42848 time : 111s received: GET /favicon.ico HTTP/1.1 heap is now: 42664 time : 187s received: GET /gpio/0 HTTP/1.1 heap is now: 44320 time : 187s received: GET /favicon.ico HTTP/1.1 heap is now: 44136 time : 223s received: GET /gpio/0 HTTP/1.1 heap is now: 44320 time : 223s received: GET /favicon.ico HTTP/1.1 heap is now: 44136

psy0rz commented 7 years ago

since that pull request isnt merged yet and it will take some time to reach upstream, here's a workaround that actually cleanups the TIME_WAITS and frees memory:

// do this before including other stuff like wificlient.h
#include "lwip/tcp_impl.h"

void tcpCleanup()
{
  while(tcp_tw_pcbs!=NULL)
  {
    tcp_abort(tcp_tw_pcbs);
  }
}

update: This goes in your main file. Call tcpCleanup regulary, for example from your loop() function.

donfrench commented 7 years ago

psy0rz: Thank you very much! I have been struggling with this problem for way too long. This did the job!!! However, it did take me a little while to figure out the details and just for others who are as dumb as me, here is what I didn't get at first. The code you posted goes into the user's app. At first I thought it went into tcp.c like one of the previous suggestions. Also, what was pretty obvious but maybe should be said is that you need a call to tcpCleanup somewhere in the loop( ). I put it at the bottom. Again, thanks for solving this problem for me! You're a peach!

pieman64 commented 7 years ago

@igrr there are quite a few threads referring to memory leaks and I'm pretty sure many of Espressif's clients will be suffering with it in some way or other.

My first question relates to the free Heap change from 2.3.0 to the latest master branch. One of our sketches has 35kb free with 2.3.0 and only 30kb free with the master branch. Why is this and is there any easy way of recovering the 5kb?

Below is a sketch that tries to implement the memory leak fix indicated in this thread. It seems to do the job but there are still some unknown occasions when the leak appears to be permanent. Do you have any idea how ESP users can ensure the free Heap always remains unchanged?

/* HeapCheckV3.ino by Costas 12 June 2017 was originally WebUdater.ino Example
   Line 15 of ESP8266HTTPUpdateServer.cpp in 
   C:\arduino-1.8.3portable\arduino-1.8.3\hardware\esp8266com\esp8266\libraries\ESP8266HTTPUpdateServer\src
   changed to:      </body></html>)";  // was </body></html>\n)";
   To upload through terminal you can use: curl -F "image=@firmware.bin" esp8266-webupdate.local/update
*/
#define HEAPCHECKER 0        // set to 1 to test HEAP loss fix
#ifdef HEAPCHECKER
  #include "lwip/tcp_impl.h" // losing bytes work around
#endif

#include <ESP8266WiFi.h>
#include <WiFiClient.h>
#include <ESP8266WebServer.h>
#include <ESP8266mDNS.h>
#include <ESP8266HTTPUpdateServer.h>

const char* host = "esp8266-webupdate";
const char* ssid = "xxxxxxxxxx";
const char* password = "xxxxxxxxxx";
uint32_t originalram;

ESP8266WebServer httpServer(80);
ESP8266HTTPUpdateServer httpUpdater;

void setup(void){

  Serial.begin(115200);
  Serial.println();
  Serial.println("Booting Sketch...");
  WiFi.mode(WIFI_AP_STA);
  WiFi.begin(ssid, password);

  while(WiFi.waitForConnectResult() != WL_CONNECTED){
    WiFi.begin(ssid, password);
    Serial.println("WiFi failed, retrying.");
  }

  MDNS.begin(host);

  httpUpdater.setup(&httpServer);
  httpServer.begin();

  MDNS.addService("http", "tcp", 80);
  Serial.printf("HTTPUpdateServer ready! Open http://%s.local/update in your browser\n", host);
  originalram = ESP.getFreeHeap();
}

//
void tcpCleanup()   // losing bytes work around
{
  while(tcp_tw_pcbs!=NULL)
  {
    tcp_abort(tcp_tw_pcbs);
  }
}
//

void loop(void){
  httpServer.handleClient();
  delay(1000);
  uint32_t ram = ESP.getFreeHeap();
  Serial.printf("RAM: %d  change %d\n", ram, (ram - originalram ));
  if(HEAPCHECKER){          // losing bytes work around
    tcpCleanup();           
    Serial.printf("tcpCleanup completed\n");
  }
}
igrr commented 7 years ago

The RAM usage difference between 2.3.0 and master is tracked in this ticket: #3227.

Regarding permanent heap loss, AFAIK there was a MEMP_NUM_TCP_PCB_TIME_WAIT option implemented in #2260, which by default limits the number of PCBs in TIME_WAIT state to 5. If you have a test case against master branch which shows that some memory is not reclaimed after a while, please share it in a new issue. Thanks.

victorconka commented 6 years ago

@psy0rz Thanx man ! that did the trick !!!!!!!!! Telegram is a piece of memory hog there, and my esp would reboot every time heap memory goes under 6500~6000(¿bits/bytes?). With that piece of code thing gets stable: heap memory usage: (no message sent) 8752; 8752; 8752; 8752; (1st message) 8088; (2nd and n'th messages) 7904 ; 7904; 7904; 7904; 7904; 7904; 7904; 7904

mribble commented 6 years ago

Thanks!!! I was actually actually hitting an exception:

Exception 29: StoreProhibited: A store referenced a page mapped with an attribute that does not permit stores

I was using ajax and was consuming 34KB of memory in about 1 minute.

Looked at the stack and saw it was probably a failed malloc. Saw this was a 184 byte issue and google lead me to this thread. Now it's worked around in 5 minutes and I was prepared for a long debug session. I'm generally a low level programmer, but the pieces are so easy to put together with this esp8266 that I'm making huge progress. I really appreciate this community!

Hope to see this mainlined so others don't hit it.

d-a-v commented 6 years ago

Does it look like #2925 ?

mribble commented 6 years ago

d-a-v, it looks similar to #2925 and I think it is likely related. However, there are some differences in the original bug description there and what I'm seeing. The original bug there says it doesn't happen for them with version 2.3.0, but I am seeing the problem on that version. Also they say the problem only happens with messages over 2048 bytes, and my messages are well under that size.

I am fine sharing my code by giving access to a private git repo (my code will eventually be open sourced, but I'm keeping it private until the kickstarter project launches). However, it does require some special hardware to run. Perhaps a better solution is I'm happy to test a solution when one becomes available.

d-a-v commented 6 years ago

So you can give a try to #3362 (you'll use lwip-v2 instead of v1.4). Please report back if this helps.

mribble commented 6 years ago

I tried master and that actually solved my issue. It consumed 4 KB more memory than the hack above, but it didn't crash like 2.3.0.

Then I tried #3362 and it seemed to cause my esp8266 to reboot without any kind of exception posted to serial (normally I see the exception and can decode the dump file). Not sure what was happening. I think any esp8266 should reproduce this issue. I posted my code and some libraries you'll need to reproduce the issue at: http://glacialwanderer.com/files/2017/Esp8266.zip

d-a-v commented 6 years ago

Glad to know it works now. about #3362, I did try with your sources. I observed the same behaviour as you did: crash with it (no crash without, webserver returning plain text 'null'). A simple sketch reproducing this behaviour is needed to sort this out (or diving into your code with the appropriate attached hardware). I did not succeed seeing the gdb magic string @ either 115200 nor 74880bps. Your sketch is an example why #3362 should leave the choice to use lwip1.4 for sorting things out.

victorconka commented 6 years ago

@mribble, thanx for sharing your experience. It made me try the master branch which seems to be more compact or compiler friendly or whatever... Now I have enough free heap for safe execution of my code. ESP.restart and ESP.reboot still don't work properly, but no unexpected reboot thanks to code @psy0rz provided .

mribble commented 6 years ago

I switched to the new ESP 2.4.0 release. It looks like they changed to using lwip v2 by default. Which we tested above and I verified it fixed the memory leak I was seeing. However the ESP 2.4.0 does not fix the memory leak. Does anyone know what might have changed? It does seem lwip v2 works better than 1.4 in that it looses memory more slowly and if I stop making ajax calls every 500 ms it does start reclaiming memory, but I have watch where over 30 seconds my app keeps making ajax transactions until there is 3KB of heap space available and then there is a failure. It starts with about 30KB of heap space and stayed at that amount with the the tcpCleanup() hack or with #3362 above. If there is an easy way to increase how aggressive it is at reclaiming memory that should work. Or if people can suggest how to reduce the clients for each transaction I'd be happy to change my code, but I don't see anything reasonable to change on my end.

I also found out the tcpCleanup() fix mentioned above doesn't work anymore because the internal structures needed by that hack have moved to lwip/priv/tcp_priv.h and when I tried to include that I get a bunch of redefinition errors. Is there some way to force more frequent cleanup of memory in lwip v2?

mribble commented 6 years ago

After more investigation I found I could change the lwip in the Arduino ide. I tried changing the from the default to the v2 mss=1460 unstable and that didn't help.

As a temporary work around I can switch back to the 1.4 version and use the workaround hack (frequent calls to tcp_abort(tcp_tw_pcbs)) I was using before. I have verified this does fix my problem.

However, I would like to help debug this problem and get it fixed in lwip v2 code. Please let me know if there are things I can try.

d-a-v commented 6 years ago

I opened a new issue for this #4213

d-a-v commented 6 years ago

Here's an updated version of tcpCleanup valid for both lwip-v1 and lwip-v2.

eighthree commented 6 years ago

@d-a-v thanks! I'm using the previous version with lwip-v1 and found that although it can free up some ram I still lose ram/time if I refresh a page/send consecutive server requests . Will switching to lwip-v2 help?

d-a-v commented 6 years ago

As far as I can tell, lwip1 has no memory leak (apart from the one addressed by tcpCleanup), so I don't think lwip2 will help with that. Maybe you need to find the leak by printing ESP.getFreeHeap() in many places of your sketch. If you locate one which does not come from your sketch then please open a new issue.

Tizana commented 6 years ago

@psy0rz regarding this code below when i include "lwip/tcp_impl.h" i got an error , no such file or directory, so include it the whole directory "C:/ ........lwip/tcp_impl.h" once i include it give me a lot of error like

error: redeclaration of 'CLOSED' CLOSED = 0, previous declaration 'tcp_state CLOSED' CLOSED = 0, error: redeclaration of 'LISTEN' LISTEN = 1, ....................

// do this before including other stuff like wificlient.h
#include "lwip/tcp_impl.h"

void tcpCleanup()
{
  while(tcp_tw_pcbs!=NULL)
  {
    tcp_abort(tcp_tw_pcbs);
  }
}
d-a-v commented 6 years ago

Check the bottom of the faq

Tizana commented 6 years ago

thx @d-a-v , i already tried the tcpCleanup() from the FAQ and nothing happen, the memory leak still exist

 // no need for #include
struct tcp_pcb;
extern struct tcp_pcb* tcp_tw_pcbs;
extern "C" void tcp_abort (struct tcp_pcb* pcb);

void tcpCleanup (void) {
  while (tcp_tw_pcbs)
    tcp_abort(tcp_tw_pcbs);
}

i tried to call tcpCleanup(); from the bottom of the loop and nothing happened, the memory still decreasing, i tried to put the tcpCleanup(); on the TOP of the loop and it didn't help at all.

i realized that the condition while (tcp_tw_pcbs) wasn't never true and and thus tcp_abort(tcp_tw_pcbs); was never called,

i tried to add a Serial.print inside the while (tcp_tw_pcbs) condition but "Cleaning ...... " didn't display at all in my terminal

void tcpCleanup (void) {
  while (tcp_tw_pcbs){
    tcp_abort(tcp_tw_pcbs);
     Serial.println("Cleaning ...... ");
  }
}

i tried to remove the while (tcp_tw_pcbs) condition but i got error and my esp restart

void tcpCleanup (void) {
    tcp_abort(tcp_tw_pcbs);
     Serial.println("Cleaning ...... ");
}

if you want to check my code it's here #4557

mribble commented 6 years ago

@Tizan,

It looks like the FAQ helped get you from not compiling to the code compiling. That is a step in the right direction. Now the problem is you still have a memory leak. Where are you calling tcpCleanup()? It should be after every client.stop().

You also asked how you reuse a connection, which is the better way to fix this. This is handled by the place making these httprequests (perhaps an ajax webpage?). There if you just keep reusing the httprequest then new versions won't be created by this esp8266 code and things will run much faster than it would if you just work around this memory 'leak'.

Tizana commented 6 years ago

thx @mribble for your answer,

so the tcp_abort(tcp_tw_pcbs); function did not triggered when i tried open connection/send data with my android phone but it work with Hercules SETUP utility software installed on my PC.

image

1- first i connect to the ESP 2- send the data 3-last send the CARRIAGE RETURN ASCII code.

the ESP receive the data and transmit to the serial, close the connection and then start the cleaning here's the serial monitor

image

but when i try with my android app that i created with xamarin the esp receive the data and transmit it to the serial and close connection but never clean the TCP. the more i send data the more i got memory leak, here's what i got in serial :

image

this is so weird why the ESP accept connection from both HERCULES and Android App extract the data and send it back to the serial and then disconnect. but if the connection was made through HERCULES app the ESP start cleaning but not with my android app ? can anybody know why ?

is there any debug option that i can look for to see what happen exactly ? i only have this one defined in my code#define DEBUG_ESP_MDNS_ERR

mribble commented 6 years ago

I'm not sure how your android or pc apps are implemented or if they have the correct options to avoid a new connection for each data transfer.

If you were willing to write your own webpage with javascript (this wouldn't be very hard as I learned how to do it about 6 months ago in a few hours) then you would control this by calling:

new XMLHttpRequest();

only once. If you called it once for each transfer then you'll have many connections and have this memory problem where esp8266 needs to track all the connections because the tcp spec says it should.

As for tools that let you see the raw tcp packet headers, I haven't ever had to do that so I'm not sure what exists. There are probably software tools that let you see the headers for tcp packets. Certainly hardware like this would let you see all this data.

donfrench commented 6 years ago

I am not sure if this problem has been answered in this thread but here is what I did that fixed the problem 100%:

Add the following line at the top of the file

include https://www.facebook.com/hashtag/include?source=feed_text

"lwip/tcp_impl.h"

And add the following method somewhere:

void tcpCleanup()

{

while(tcp_tw_pcbs!=NULL)

{

tcp_abort(tcp_tw_pcbs);

}

}

And finally add a call to tcpCleanup( ) at the bottom of the loop method.

This is the solution for apps written in C, not sure about Lua or any other language.

-- Don

On Sat, Mar 24, 2018 at 2:36 PM, Maurice Ribble notifications@github.com wrote:

I'm not sure how your android or pc apps are implemented or if they have the correct options to avoid a new connection for each data transfer.

If you were willing to write your own webpage with javascript (this wouldn't be very hard as I learned how to do it about 6 months ago in a few hours) then you would control this by calling:

new XMLHttpRequest();

only once. If you called it once for each transfer then you'll have many connections and have this memory problem where esp8266 needs to track all the connections because the tcp spec says it should.

As for tools that let you see the raw tcp packet headers, I haven't ever had to do that so I'm not sure what exists. There are probably software tools that let you see the headers for tcp packets. Certainly hardware like this https://www.kickstarter.com/projects/mossmann/hackrf-an-open-source-sdr-platform would let you see all this data.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/esp8266/Arduino/issues/1923#issuecomment-375926590, or mute the thread https://github.com/notifications/unsubscribe-auth/AEVNXJVo0-7omogAfrmUEPOlV2bH9X5jks5thrxigaJpZM4IJDi- .

Tizana commented 6 years ago

i maybe know why tcp_abort was not executed when i used my android app (developed with Xamarin) as client. if i connect the android app to the esp and send data, the tcp_abort won't be executed until i close the app. putting the app in the background won't work the app should be killed(closed).

for example in my android app i have a button send which is responsible to connect to the ESP and send a data. if i open the APP and click three time to button send the tcp_abort will not be executed at all, once i close(kill) the app the tcp_abort is executed three time in a row.

for information i add the tcpCleanup(); two time, in the top of the loop and in the bottom.

void loop() 
{
tcpCleanup();`
...........
..........
tcpCleanup();`
}

i don't have a knowledge in the TCP Protocol so i can't explain why this happen and how the TCP deal with these situation.

i succeeded to get around with this problem in my Xamarin app but i'm not convinced with my solution.

mribble commented 6 years ago

In my javascript I created a ringbuffer of XMLHttpRequest objects so that I could reuse these. My understanding is this should reuse the connection and prevent the 184 byte memory growth. This is important to me because I'm using a dynamic ajax that causes 4 transfers per second and I'll quickly exhaust memory.

This worked fine for lwIP v1.4 Higher Bandwidth. It also works for lwIP v2.0 Higher Bandwidth. However the default is now lwIP v2.0 Lower Memory, and it causes the memory to grow until I run out of memory. I find this odd that you are growing the table of connections even when I'm reusing connections. It seems like there might be a bug here, but I haven't looked at this code. It feels like perhaps you are only reusing the latest connection (since I have a small ring buffer that doesn't help me), but still the code is wasting memory to track more than just one connection. Could someone explain if this makes sense?

Calling tcpCleanup() does work around the issue.

d-a-v commented 6 years ago

without hacking sources, with tcpdump you can check if the same connection is indeed reused just by looking at the TCP port number. The difference between the two versions of lwip2 is only MSS so from the App point of view, especially if data are small there shouldn't be any difference.

icssww commented 6 years ago

regarding this code below when i include "lwip/tcp_impl.h" i got an error , no such file or directory, so include it the whole directory "C:/ ........lwip/tcp_impl.h"

I have been searching a lot, still unable to figure out how to get this library? Where to place this library? Will appreciate any support, thanks

d-a-v commented 6 years ago

Check the snippet in the documentation's FAQ. Change is needed because of lwip v2.

icssww commented 6 years ago

thanks for the prompt response @d-a-v , can you please help me with the link to FAQ/documentation, apologies for the inconvinience

d-a-v commented 6 years ago

It's right on your screen: https://github.com/esp8266/Arduino/ then Content > Documentation > latest > FAQ

icssww commented 6 years ago

Thanks for your prompt response, it helped big time

MrSuhov commented 6 years ago

Seems like I am facing this issue in universal-telegram-bot where I have to call bot.Update method every second resulting in Exception (29) when heap falls to about 6k. Workaround with cleaning TCP PCBs doesn't work for me (https://arduino-esp8266.readthedocs.io/en/latest/faq/readme.html). Board: wemos d1, compile options below: compile01 Running out of heap in about 15 minutes. Measuring heap size before and after bot.Update() method ends with this: Free heap before bot.Update: 7032, free heap after bot.Update: 6648 Free heap before bot.Update: 6976, free heap after bot.Update: 6896 Free heap before bot.Update: 6920, free heap after bot.Update: 6536 Free heap before bot.Update: 6864, free heap after bot.Update: 6784 Free heap before bot.Update: 6808, free heap after bot.Update: 6616 Free heap before bot.Update: 6752, free heap after bot.Update: 6368 Free heap before bot.Update: 6696, free heap after bot.Update: 6616 Free heap before bot.Update: 6640, free heap after bot.Update: 6256 Free heap before bot.Update: 6584, free heap after bot.Update: 6200 Free heap before bot.Update: 6528, free heap after bot.Update: 6144 Free heap before bot.Update: 6472, free heap after bot.Update: 6280 Free heap before bot.Update: 6416, free heap after bot.Update: 6032 Free heap before bot.Update: 6360, free heap after bot.Update: 6280 Free heap before bot.Update: 6304, free heap after bot.Update: 5920 Free heap before bot.Update: 6248, free heap after bot.Update: 6168 Free heap before bot.Update: 6192, free heap after bot.Update: 5808 Free heap before bot.Update: 6136 Exception (29): epc1=0x4020e88a epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000004 depc=0x00000000

Secure client is used for establishing connection to telegram bot api. Any ideas on how to overcome this?

d-a-v commented 6 years ago

@MrSuhov if you are using 2.4.1 core, there is a known leak which is fixed in the current git version. tcpCleanup still applies though.

MrSuhov commented 6 years ago

@d-a-v Thanks a lot! A fresh git clone https://github.com/esp8266/Arduino.git esp8266 was really helpful - heap keeps on a constant level!

felixbarzin commented 6 years ago

@d-a-v many thanks :)

d-a-v commented 6 years ago

FYI, tcpCleanup is not anymore needed in latest git.

ivelichkevich commented 5 years ago

Is it possible to get the spot fix?

victorconka commented 5 years ago

@ivelichkevich personally i've moved on from this usecase towards using raspberry pi zero/orange pi zero as a server which does all the logic, including telegram commands/messages/etc. esp8266 acts as a simple node that communicates via mqtt with the server. Has plenty of free memory now. Hope that's useful

d-a-v commented 5 years ago

Is it possible to get the spot fix?

What does it mean ?

personally i've moved on from this usecase towards using (linux)

That's a choice. There's less fun :)

This issue is not around anymore since core-2.4.2. For previous core version, it is well described in the FAQ.

ivelichkevich commented 5 years ago

What does it mean ?

commits hashes for this fix or pease of code to fix leak in 2.4.1 I can use 2.4.2

Sorry, Where can I find FAQ?

d-a-v commented 5 years ago

The FAQ is in the documentation. Documentation link has been recently made more visible in the main page (Quick Links) in https://github.com/esp8266/Arduino/.

How it has been fixed is an idea of @me-no-dev:

Links are there: links & macro and lwip-v2 patch

This patch will be proposed to lwIP developpers at some point.