ESPhttpUpdate memory leak

[sglvladi]

Basic Infos

Hardware

Hardware: ESP-12
Core Version: 2.2.0

Description

HI there!

So, I have taken the example "httpUpdate.ino" and pointed the Updater to a php file on our local http server, which shall perform basic version checking and trigger the update if the right conditions are met. The source of the .php file is basically a copy and paste (with minor changes and adding a missing "?>" at the end) of the source example given under "Advanced updater" section of the link below:

http://esp8266.github.io/Arduino/versions/2.2.0/doc/ota_updates/readme.html#http-server

I should probably mention here that connecting to the server, receiving the .bin file as well as performing the update have all been tested and confirmed to work just fine.

To recreate the problem of interest, I have intentionally set both the requested version (in .ino file) and the stored version (in the .php file) the same, such that the device does not proceed to updating the firmware, but rather receives an "HTTP_UPDATE_NO_UPDATES" message on every cycle. All fine up to here!

The full .ino source code can be viewed below. As you can see, I have added a print out to display the available heap size on every iteration of the loop() function. What I can observe from Serial is a rapid drop of the free heap and, without any added loop delays, the device runs out of memory in about 45 seconds. Eventually, the device starts failing to send headers and finally spits out an Exception (29), which I assume simply means that some memory location has been overwritten. What is also interesting is that the drops are not the same in every loop() iteration, but rather occur randomly and are of random size. (as far as I can see)

Is this an issue, or am I missing something out?

Thanks much in advance.

Settings in IDE

Module: NodeMCU 1.0 (ESP-12E Module)
Flash Size: 4M (3M SPIFFS)
CPU Frequency: 80Mhz
Flash Mode: Unsure
Flash Frequency: Unsure
Upload Using: SERIAL
Reset Method: nodemcu

Sketch

/**
 * httpUpdate.ino
 *
 *  Created on: 27.11.2015
 *
 */

#include <Arduino.h>

#include <ESP8266WiFi.h>
#include <ESP8266WiFiMulti.h>

#include <ESP8266HTTPClient.h>
#include <ESP8266httpUpdate.h>

#define USE_SERIAL Serial

ESP8266WiFiMulti WiFiMulti;

void setup() {

    USE_SERIAL.begin(115200);
    // USE_SERIAL.setDebugOutput(true);

    USE_SERIAL.println();
    USE_SERIAL.println();
    USE_SERIAL.println();

    for(uint8_t t = 4; t > 0; t--) {
        USE_SERIAL.printf("[SETUP] WAIT %d...\n", t);
        USE_SERIAL.flush();
        delay(1000);
    }

    WiFiMulti.addAP("SSID", "PASSWORD");

}

void loop() {
    // wait for WiFi connection
    if((WiFiMulti.run() == WL_CONNECTED)) {
        Serial.print("Free heap: "); Serial.println(ESP.getFreeHeap());
        t_httpUpdate_return ret = ESPhttpUpdate.update("SERVER_IP", 80, "/update/software_update.php", "plaketa_mux_ads_ds2431.ino");
        //t_httpUpdate_return  ret = ESPhttpUpdate.update("https://server/file.bin");

        switch(ret) {
            case HTTP_UPDATE_FAILED:
                USE_SERIAL.printf("HTTP_UPDATE_FAILD Error (%d): %s", ESPhttpUpdate.getLastError(), ESPhttpUpdate.getLastErrorString().c_str());
                break;

            case HTTP_UPDATE_NO_UPDATES:
                USE_SERIAL.println("HTTP_UPDATE_NO_UPDATES");
                break;

            case HTTP_UPDATE_OK:
                USE_SERIAL.println("HTTP_UPDATE_OK");
                break;
        }
    }
}

[devyte]

@sglvladi
you don't have any check in the loop to space out the connection attempts. The loop is executed repeatedly, so you are generating excessive connection attempts. I could be wrong, but I believe that what is happening is that you are accumulating sockets in TIME_WAIT state, or something along those lines.

Please put a time check in the loop, and try connection attempts only once every e.g.: 10s. I would expect heap to drop to some point, then stabilize. If you then stop the connection attempts, I think heap should recover.
If heap still monotonically drops and the ESP crashes, then yes, there is likely a leak.

[devyte]

@sglvladi did you test with spaced out requests? In any case, I think the example should be updated with that.
Also, I suggest trying PR #3362 , which seems to improve socket comms.

[d-a-v]

#2925 shows that lwip's heap does not recover in some case. #3362 addresses this case too.
It is indeed worth a try.

[devyte]

@sglvladi will you be testing with release 2.4.0?

[devyte]

Closing due to lack of feedback in several months.