Part Number: CC2642R
Tool/software: Code Composer Studio
Hi everyone,
we observer some cases were the BLE stack gets stuck in xdc_runtime_SysCallback_defaultAbort.
What seems odd to me is the heapMem linked list, which contains at least 2 dangling entries and some entries are referenced more than once:
Here are the Variables from the above shown HeapMem_freeUnprotected retrieved from the call-stack:
Can you give me any hints how to get to the root-cause?
Kind regards
Clemens
Hi Clemens,
Based on the fact that an assert call was made in the HeapMem_free() call, I looked in the HeapMem.c file. The only assert in that function is
Assert_isTrue((((UArg)addr & (obj->minBlockAlign - 1)) == 0), HeapMem_A_invalidFree);
It looks like the ICALL code is trying to free something that is not on a proper alignment value. I'll ping the developers of this code.
btw: thanks for enabling asserts! It's the first thing I recommend when "strange" things happen with an application.
Regarding the dangling addresses. There is an open jira to remove the "next" address from the "In Use" blocks. The next pointer is only meaningful in the free blocks (it's the linked list of the free blocks). Once allocated, the application generally over-writes this field anyway. The ROV view should look like this (or have next be "N/A" instead of being blank).
Todd
