1 of 1 people found this helpful
There is a memory leak in the release of BESL that is included in binary form with version 3.7.0 of the wiced sdk. Only way to fix it is to patch in an older version of BESL into your SDK.
WICED/security/BESL is were it is located. The leak appears to be in the pre-compiled binary so pin pointing the leak is difficult but it's somewhere with in the library it's self.
When attempting to use any SSL/TLS based communication that relies on BESL will quickly crash the board as it runs out of heap memory.
2 of 2 people found this helpful
Patch in an older version of BESL to latest SDK is wrong direction to do, then you lost SNI and other new improvements.
The correct way to fix it is to get official fix ASAP.
I agree patching with old version of BESL could cause more issues later since we don't know what's inside the lib file and moreover they are not tested together thoroughly. If Cypress/Broadcom didn't patch it with a beta lib, we should just stick with 3.5.2 for now.
This memory leak issue was reported for more than a month.
I was expecting a fix will be available quickly.
Unfortunately the fix is still not available, it forces people to use old sdk now.
WICED seems to use dynamic memory allocation very heavily, to its detriment.
Even in their host_rtos_create_thread, I don't think there is even an option provided to use statically allocated stacks for tasks.
There is a reason that NASA totally disallows dynamic memory in all their embedded code ...
Has anyone tried MALLOC_DEBUG with real code? And/or attacked this problem with a trace probe?
In the BESL archive files, it looks like there are only about 25 calls to malloc in one form or another, only 3 associated with tls_host_malloc. And the code for those is provided, just a wrapper around malloc_named or malloc.
I got same WICED_TLS_ERROR_RECORD_OVERFLOW in 3.7.0 .
Anybody know, this error fixed in 3.7.7 sdk version or in 5.x ?