ESP8266 Community Forum

limbo wrote:I know this is a known issue.

Where did you pick that up? It's neither a known issue nor were you quoting an actual example from our documentation IIRC. The closest we have is with http://nodemcu.readthedocs.io/en/latest ... etsocketon



If you access the `srv` variable within a `srv.on` callback function (as with your example) you're actually creating a memory leak. Some explanation is here: http://stackoverflow.com/a/37379426/131929.

What you're likely seeing (besides the above) is too many open sockets in TIME_WAIT status i.e. not yet closed. https://github.com/nodemcu/nodemcu-firmware/pull/1838 reduced the number of seconds such sockets should be kept around. You might also try to replace `Connection: keep-alive` with `Connection: close` and see how the server reacts.

If you access the `srv` variable within a `srv.on` callback function (as with your example) you're actually creating a memory leak. - See more at: posting.php?mode=reply&f=24&t=14370#sthash.7gLdOrHy.dpuf

If accessing "srv" variable with ":on" callback function will create a memory leak, then what is the proper way to open a client connection, send or recieve data and close the connection without leaking?

I am trying to create a simple program the monitors a GPIO pin for button press, and when it's pressed, connect to a server, send a message, and disconnect. Then wait for another button press. No matter what I have tried so far, I am always leaking memory.

Here is my current code


Here is the output from the console



Each time the button triggers, the heap drops by about 200 bytes. This will continue until heap is exhausted.

UPDATE
It looks like my issue was due to TCP_WAIT sockets as well. I restructured my code a little bit, and I changed my testing process. Now, I hit the button, and wait several minutes before hitting the button again (which will be how the device will work in real world use case). Now, I see the heap staying at the same size between each button press. If I hit the button multiple times, I do see the heap size decrease with each button press. I assume this is because each time I press the button, I create a new socket, which then remains in TIME_WAIT for a period. If I wait several minutes, and hit the button again, the heap jumps back up.

For the record, here is the most recent version of my code I am testing

And here is the output spread out of a 12 hour test period

The first few test were performed after other testing, so the out heap stayed around 39512. The last few log enteries were performed at least 10 minutes apart and the last being 10 hours apart, and the board seems to have stablized around 39720.

So in my case, there does not appear to be a leak after all. I just needed to wait for the sockets to full close before the heap is released.

BrettJ123 wrote:It looks like my issue was due to TCP_WAIT sockets as well.

As you see in the issue I referenced TIME_WAIT is going to be significantly reduced with the next release. Furthermore, if you communicate over HTTP you can send a "Connection: close" header to instruct the client to hang up.