Not enough memory after ~120 refresh of the same page

[LionelKonrad]

Hello,

I've just tested the latest version with a esp8266-01 (1MB flash)
I added only html/index.html with a little content <H1>OK</H1>

I can load the content with my browser, but I made a test : refresh ~120x the page...then the esp crashed (not enough memory)...

I have the same problem with my home-made version of a http server...I think there is a memory-leaks with the socket management, but where?

[marcoskirsch]

It's likely that the bug is in the firmware code. Have you looked at their open issues list?

[LionelKonrad]

There is several issues in relation with memory leaks.
For exemple : nodemcu/nodemcu-firmware#1804
A proposed solution is to put 'Connection: close' in response header, but it doesn't seems to work because the server already put it.
To investigate...

[ATAMAH]

Try to change the timeout to zero. In file httpserver.lua:

local s = net.createServer(net.TCP, 10) -- 10 seconds client timeout

[arthurafarias]

Same here, I'm serving an static html, in the second refresh it gives me the same message: "Not enought memory".

[HHHartmann]

Hi, I also have this issue.
Before my ESP runs into the "out of memory" error it shows "E:M 1584" with varying numbers on the console.
I found a related issue on the ESP Python project which is analyzed quite good
micropython/micropython#1971

Says there: "Generally, this error means that "OS" is running out of heap space (that's different heap than uPy heap). Usual cause is receiving from network too slow, or vice-versa, sending too fast. Or rather, not sending fast, but sending too little data per packet, which causes too many packets allocated."

Together with the fact, that our send does not use the callback sent function to know when the send is finished I suspect, that the sending is not working properly yet. Or am I overseeing something?

In the nodemcu doc is says explicitely, "Multiple consecutive send() calls aren't guaranteed to work (and often don't) as network requests are treated as separate tasks by the SDK. Instead, subscribe to the "sent" event on the socket and send additional data (or close) in that callback. See #730 for details."

So hopefully I will be able to sort out the concurrent stuff together with the send and callback on the wekend.
(and hopefully that will solve the issue)

[coderkevin]

I'm also experiencing this using just http.post() to a local IP address URL. I get about 70 "HTTP client: Connection timeout" lines before the unit crashes and restarts. As long as the HTTP requests complete without errors, everything is fine though. 🤔

[HHHartmann]

OK the stuff above about the wrong usage of send was crap. (I found the on sent callback ;-)
I added some memory cleanup to the server and changed serving static pages completely.
See issue 83. We can now serve up to (ore even more) six cars on one page. And I can reload it several times without crash (havn*t tried the exact number though).

[marcoskirsch]

I added some memory cleanup to the server and changed serving static pages completely.

@HHHartmann so your changes fix this?

[HHHartmann]

I am just preparing an automatic test to test this. Will have a PR latest this weekend

[coderkevin]

Will this help client requests too? Or just the server?

[HHHartmann]

@coderkevin I ama fraid I don't understand the question.

@marcelstoer It might fix this issue. But there seems to be a problem freeing memory of closed connections in the nodemcu which should be fixed in the new 2.1 release. Will test with nodemcu 2.0 and 2.1 these days

I added PR #92 which automates the task of reloading the same page and counts the reloads.
Makes it easier to test.

[HHHartmann]

OK here is what I found

requests before failure

count	current master	curent master + new static serving
nodemcu < 2.1	90	> 300
nodemcu 2.1	>300	not tested

The new nodemcu releases some memory of the TCP connections faster (10 sec instead of 60)
The new static handling has a smaller memory footprint so there is enough spare memory for he TCP memory waste.