Memory leak in WiFiClientSecure on repeated WiFiServerSecure connections

[stefaandesmet2003]

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]

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]

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

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]

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