ESPAsyncWebServer icon indicating copy to clipboard operation
ESPAsyncWebServer copied to clipboard

AsyncWebHandler memory leak

Open Di-Strix opened this issue 3 years ago • 9 comments

Hardware: Wemos D1 mini 4mb. I used PlatformIO with Arduino framework. ESP8266 core version: 3.2.0

Sketch to reproduce:
#include <Arduino.h>
#include <ESPAsyncWebServer.h>

AsyncWebServer server(80);

void setup()
{
  Serial.begin(115200);
  Serial.println("\n\n\n\n\n");

  Serial.println("Free heap at start: " + (String)ESP.getFreeHeap());

  for (size_t i = 0; i < 100; i++) {
    auto h = server.on("*", [](AsyncWebServerRequest* request) {});
    server.removeHandler(&h);
  }

  Serial.println("Free heap after 100 creations and removals: " + (String)ESP.getFreeHeap());

  for (size_t i = 0; i < 100; i++) {
    auto h = server.on("*", [](AsyncWebServerRequest* request) {});
    server.removeHandler(&h);
  }

  Serial.println("Free heap after 200 creations and removals: " + (String)ESP.getFreeHeap());
}

void loop()
{
}

Sketch run results:

Free heap at start: 37592
Free heap after 100 creations and removals: 22392
Free heap after 200 creations and removals: 7192

It appears that LinkedList::remove could not find just registered handler and as a result - it is not deleted. According to the docs I should not do anything after calling removeHandler. Am I missing something?

Part from doc's 'Remove handlers and rewrites' section
// save callback for particular URL path
auto handler = server.on("/some/path", [](AsyncWebServerRequest *request){
  //do something useful
});
// when you don't need handler anymore remove it
server.removeHandler(&handler);

Di-Strix avatar Apr 16 '22 12:04 Di-Strix

I see that callback-register functions return a reference to AsyncCallbackWebHandler. It would be much easier to store and operate them if they are pointers, isn't it?

Di-Strix avatar Apr 16 '22 12:04 Di-Strix

[STALE_SET] This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

stale[bot] avatar Jul 10 '22 11:07 stale[bot]

UP

blikkk avatar Jul 19 '22 12:07 blikkk

[STALE_CLR] This issue has been removed from the stale queue. Please ensure activity to keep it openin the future.

stale[bot] avatar Jul 19 '22 12:07 stale[bot]

I will be really disappointed if it turns out that such a cool library is dead😕

But its current activity doesn't live up to the best expectations...

Di-Strix avatar Aug 04 '22 23:08 Di-Strix

[STALE_SET] This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

stale[bot] avatar Nov 02 '22 00:11 stale[bot]

Found that same issue. Any news or pull request around we can apply as a patch?

kmomberg avatar Feb 12 '24 22:02 kmomberg

[STALE_CLR] This issue has been removed from the stale queue. Please ensure activity to keep it openin the future.

stale[bot] avatar Feb 12 '24 22:02 stale[bot]

@kmomberg I don't follow this repo, but I don't think anyone investigated this issue. The only easy way I see to fix this is to rewrite callback-register function to return a pointer to the AsyncCallbackWebHandler with subsequent proper handling of pointers and adapting library to use pointers. This will completely break compatibility, but should fix the issue.

Di-Strix avatar Feb 12 '24 22:02 Di-Strix