-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Memory leak in WiFiClientSecure on repeated WiFiServerSecure connections #4302
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
This is a repeatable OOM error. AXTLS doesn't ever check for malloc() returning NULL, so you get crashes like this instead of warning messages or dropped connections. Steps to repeat are simply run the example and do several HTTPs requests to it. Around 8KB per connection seems to be lost. Most likely due to something w/the shared SSL context when used by apps which do object-copies of the WiFiClientSecure. So the simple WiFiHTTPSServer.ino example doesn't have this issue as it never does object copies of the client. |
@stefaandesmet2003 I just edited the title to reflect what I've seen, as this is not a problem in the webserver but in the backend libs supporting it. |
I've torn down and rebuilt the standard SSL client and server using shared_ptr and can remove the memory leak, but there's a race condition with ClientContext vs. SSL shutdown. Still needs work, but it's stable now until it runs out of RAM (about 200 bytes per connection lost now) |
Fixes esp8266#4302 The refcnt setup for the WiFiClientSecure's SSLContext and ClientContext had issues in certain conditions, causing a massive memory leak on each SSL server connection. Depending on the state of the machine, after two or three connections it would OOM and crash. This patch replaces most of the refcnt operations with C++11 shared_ptr operations, cleaning up the code substantially and removing the leakage. Also fixes a race condition where ClientContext was free'd before the SSLContext was stopped/shutdown. When the SSLContext tried to do ssl_free, axtls would attempt to send out the real SSL disconnect bits over the wire, however by this time the ClientContext is invalid and it would fault.
@stefaandesmet2003 Can you check #4305 out and do some add'l testing? I've had my server running in a loop for about 20 minutes requesting HTTPS pages, and it seems both stable and to have no memory leaks. |
Basic Infos
Hardware
Hardware: wemos D1 mini
Core Version: 2.4.0 + WebServerSecure + WiFiServerSecure manually added in (or latest github)
Description
While testing pull request #3001 I ran into a couple of problems, see conversation @ #3001 .
Source code, serial output and stack trace in attached files.
Hi @earlephilhower ,
I did some more testing. The WiFiHTTPSServer example works consistently without resets. But every first request from the browser is not correctly decrypted : the 'req' string is empty, serial prints 'invalid request', and client.print (http 404) never arrives at the browser. Every second request (probably a retry from the browser) is correctly decrypted : req : GET /gpio/1 HTTP/1.1. In the output log i added a ESP.getFreeHeap() printout every 5 seconds. Heap is ok here.
The HelloServerSecure example now works without reset for 1 browser request (i used lwip v2 lower memory variant), but then esp8266 resets systematically on the 2nd request. From the same ESP.getFreeHeap() printout every 5s, you see initial heap size of 35k is reduced to 5k after the first browser request, and is not restored. Then the 2nd request (reload page) fails with a reset.
Main difference between the 2 examples is the ESP8266WebServerSecure library.
Could you please check if you have the same behavior on your hardware?
Cheers,
Settings in IDE
Module: wemos D1 mini
Flash Size: 4MB
CPU Frequency: 80Mhz & 160MHz same behavior
HelloServerSecure_StacktraceOnReset.txt
WiFiHTTPSServer_HelloServerSecure_CodeAndSerialOutput.zip
The text was updated successfully, but these errors were encountered: