User case : I'm connected to AWS IOT using mbedtls, I'm checking the internet connectivity opening a socket to google.com:80 and sending a byte every 15 seconds, also on each 4 minutes I have to close and re-open the socket, because google closes the peer after 4 minutes. How to test: I go to my modem interface and I disconnect the adsl client for some seconds and then re-connect it again, after some seconds the google socket fails to send/reopen resulting on an internet connectivity failed event. Thus the network controller fully destroys the mbedtls, waits for the internet (google socket) and then re-connects the mbedtls again, so between each internet disconnection/re-connection I see a memory leak of about 400 bytes. NOTE: When I disconnect the wifi interface and reconnect it again, most of the memory leak is gone. The leak is related to the mbedtls or lwip.

OBS: The RTOS_SDK mbedtls library "net" is using the original net.c file from ESP8266_RTOS_SDK\third_party\mbedtls\library, while the NON_OS is using the "espconn_mebdtls.c" wrapper that uses lwip behind. The RTOS_SDK mbedtls shouldn't be using the "espconn" wrapper instead of the original net file?

Hi, Memory leaking may happen at first, but the total leaking memory bytes is constant(It means that it will not increase forever). This is the LWIP internal TCP management policy. So if the leaking memory don't continue to happen, it is normal and OK.

donghengqaz wrote:Hi, Memory leaking may happen at first, but the total leaking memory bytes is constant(It means that it will not increase forever). This is the LWIP internal TCP management policy. So if the leaking memory don't continue to happen, it is normal and OK.

Hi donghengqaz,

In this case the leaking is happening forever, until the wifi(physical layer) disconnects and re-connects again or the device is restarted.This is the scenario: mbedtls uses about 30kb of RAM, during the handshake, mbedtls uses about 17kb of RAM. So at every handshake I see a memory leak of 400bytes after an internet connectivity failed event. Therefore, lets say that we start the application with 20kb of memory available during the mbedtls handshake, then after about 7 network re-connections (internet connectivity and mbedtls connection to AWS), the application will run out of memory during the mbedtls handshake step, resulting in a critical system failure.The application needs to be able to reconnect the network as many times as necessary without any kind of issues to guarantee stability and reliability.

I've tried all the possible ways to avoid memory leaks, using a global pcb with global pbuf, allocating pcb and pbuf on each ping request and then destroying.. I've also added a lot of vTaskEnterCritical() and ExitCritical on the lwip calls, but it didn't change anything. All the ways goes to the same memory leak. It seems that this memory leak of RAW icmp implementation is the same memory leak related to the lwip TCP socket. So I really think that the problems is internal, probably some integration between the lwip and esp8266 network stack/tx/rx task.

Another thing that I noticed on the RAW implementation is about the "struct icmp_echo_hdr", when calling the function "ping_prepare_echo" and setting the ping ID and seq_num, it doesn't take any effect, the ping echo response has always the same ID and seq_num of "4368 and 4882". When the internet is disconnected, the ping_recv callback still receives a ping echo with a different ping ID and 0ms of response time.

Documentation

About Us

Espressif Systems is a fabless semiconductor company providing cutting-edge low power WiFi SoCs and wireless solutions for wireless communications and Internet of Things applications. We are the manufacturer of ESP8266EX.