Skip to content

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

Closed
stefaandesmet2003 opened this issue Feb 5, 2018 · 4 comments

Comments

@stefaandesmet2003
Copy link

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

@earlephilhower
Copy link
Collaborator

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.

@earlephilhower earlephilhower self-assigned this Feb 5, 2018
@earlephilhower earlephilhower changed the title Memory leak in WebServerSecure on repeated connections Memory leak in WiFiClientSecure on repeated WiFiServerSecure connections Feb 5, 2018
@earlephilhower
Copy link
Collaborator

@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.

@earlephilhower
Copy link
Collaborator

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)

earlephilhower added a commit to earlephilhower/Arduino that referenced this issue Feb 6, 2018
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.
@earlephilhower
Copy link
Collaborator

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants