I’m not sure if this is the right place, but maybe the mbedTLS gurus assume static mutexes so it becomes an incompatibility between mbedTLS and FreeRTOS? Otherwise it’s maybe an mbedTLS bug that I need to report elsewhere?
= mbed TLS 2.16.9 branch released 2020-12-11
ecp_mul_comb creates a mutex via mbedtls_mutex_init() which ends up being aws_mbedtls_mutex_init() which calls xQueueCreateMutex() which calls pvPortMalloc() (with many intermediaries).
Later, ecp_mul_comb calls ecp_drbg_free() which calls mbedtls_ctr_drbg_free() which deletes the mutex, but then ecp_drbg_free() immediately re-creates the mutex using mbedtls_mutex_init().
So when ecp_mul_comb exits there is still a mutex malloc’ed but not free’ed. ecp_mul_comb does return a pointer to the context which contains a pointer to the mutex but I can’t see that anybody deletes the mutex in the end.
So when I close my MQTT connection and re-open it, memory leaks.
Because all of this is surrounded by #ifndef MBEDTLS_ECP_NO_INTERNAL_RNG the problem goes away when I #define MBEDTLS_ECP_NO_INTERNAL_RNG. This was not present in the previous version of the FreeRTOS bundle I worked with, so I’m thinking this is a recent security enhancement that has not been fully tested?
Combined with my previous post, I’m now down to one malloc-without-a-free out of the four I started this week with. Now to track down the last one.