[mbedTLS] leak on mbedtls_net_connect [spoiler lwip_getaddrinfo]

[francesco.prosperi]

Hi guys,

Testing the sdk demo https_request_main (modified to free and reinitialize the ssl session endlessly),
I noticed a memory leak occurring at each round.

The modified code and my output log are attached.

Am I doing something wrong? Am I missing some api call?

P.S. Testing the desktop (programs/ssl/ssl_client1.c of https://github.com/ARMmbed/mbedtls),
the same leak occurs.

Thanks for the great work and for the eventual help.

Regards,
FP

[ESP_Angus]

Hi FP,

I'm not entirely sure what you're seeing here. The attached code seems like it shouldn't leak memory, at least at a glance.

There is one thing in ESP-IDF which can look like a memory leak, which is that TCP sockets have to stay in the TIME_WAIT state for a period of time after the connection closed. This means that any program which opens then closes TCP sockets in a tight loop will appear to leak memory for a minute or two, after which time the older sockets start timing out and memory usage will stabilise.

You've mentioned lwip_getaddrinfo() and mbedtls_net_connect() in the subject of the thread but not anywhere in the post. Can you explain further? In mbedtls/port/net_socket.c there is a call to freeaddrinfo() before mbedtls_net_connect() returns. Is this not working properly?

The best thing you can do to track down possible memory leaks in esp-idf is to use the heap tracing facilities in the master branch (pre-V3.0):
https://esp-idf.readthedocs.io/en/lates ... ap-tracing

(Note that the "False Positive Memory Leaks" heading in that document also mentions TIME_WAIT as one cause of behaviour which may look like a leak in the short term, but is not.)

[francesco.prosperi]

Hi ESP_Angus,
thanks for the prompt reply.

Your suggestion makes totally sense.

Valgrind seems to put me off-track by reporting that the "leak" happens inside lwip_getaddrinfo.

==5934== HEAP SUMMARY:
==5934== in use at exit: 5,272 bytes in 7 blocks
....
==5934== by 0x492D2E4: gaih_inet.constprop.7 (getaddrinfo.c:790)
==5934== by 0x492E430: getaddrinfo (getaddrinfo.c:2304)
==5934== by 0x113AEF: mbedtls_net_connect (in /home/francesco/mbedtls/programs/ssl/ssl_client1)
==5934== by 0x11289D: main (in /home/francesco/mbedtls/programs/ssl/ssl_client1)

I'll read the page about heap debugging and do some more tests to confirm your point.

Thanks again for the support.

FP

[francesco.prosperi]

Hi ESP_Angus,

I slightly modified to previous code to test the release of the memory on the long term.

The current demo allocates/deallocates (completing successfully the https request at each round) for 15 rounds.
After the requests, I put the firmware in idle, monitoring the heap usage only (no actions).

As you can see by the log, after about 10 cycles the heap memory usage becomes stable (and that much is pretty good).

On the other side, the heap usage does not decrease (I waited up to 15 minutes). The run in the log attached is about 6 minutes.

The heap usage output is done every 5 seconds.

Is this right?

Your last post led me thinking that I would have such memory back (at least in the long term).

FP