Hi Roshini,

[please always repy to the list, this allows other people to help as well]

Thanks for your reply. I am running into one weird issue in memory allocation part. Before moving to the issue, let me explain my configuration macros.  MBEDTLS_SSL_MAX_CONTENT_LEN - Default value I have enabled platform memory macros

I have allocated heap memory of around 60KB, which I though is sufficient for DTLS.  I am using ecc based certificates.  And also my application contains CoAP secured using DTLS.  The issue is -

1. I am sending coap request and I successfully obtain the response also.

I continue the above step for 3 times. 3rd time I am observing the debug message - "ssl_srv.c:3808: |1| mbedtls_ecdh_calc_secret() returned -16 (-0x0010)". The return code corresponds to memory allocation failure in BIGNUM. To investigate further, I have customized my calloc function to print the function name - from which allocation failure is done. I can see the memory allocation failure happened at API "mbedtls_mpi_grow".

Further, I have increased the heap memory. But still issue is reproducing after certain number of iterations.

Do you need to change any configuration setting? Not sure why this is happening? I am facing this issue for past 1 week.   It would be really helpful if you can guide me in this issue.

If the connection is succeeding the first few times, and failing after a number of times with an out-of-memory message (and the larger the heap, the longer it goes before failing), to me this suggests two possible causes:

1. There could be a memory leak somewhere, in Mbed TLS or in other code used by your application. We do our best to avoid those in Mbed TLS, so I'd like to hope it's unlikely there is a leak in Mbed TLS, but it can't be completely excluded. If the core issue is a memory leak, it could also be in other parts of the code used by your application.

One way to check for this would be to print out the current state of the allocator after each successful connection, and check if there is more memory still in use after each connection than after the previous connection.

2. Alternatively, if there is no leak, it could be that the heap is getting so fragmented that the allocator can't find enough consecutive space. Given that the failure happens in `mpi_grow()` which usually makes rather small allocations, that's probably not likely the issue here, but I thought I'd mention it for completeness.

Regards, Manuel.