Instruction update for the Heap tracker and question

[bawilless]

First off, thank you for publishing this tool! I'm trying to use the tool to help me locate a memory leak and I have one documentation suggesting and a question.

The instructions should include a step to add the heap_tracker.c file in the CMakeLists.txt file. For the AzureIoT example the user would add the following two lines to the common/CMakeLists.txt file.

${CMAKE_CURRENT_LIST_DIR}/heap_tracker_lib.c
${CMAKE_CURRENT_LIST_DIR}/heap_tracker_lib.h

I'm trying to use the library in an application that connects to my IoTHub and I see warnings printed out . .
Heap-Tracker lib: WARNING! Native free(0xbef04e10) was called instead of _free() helper: 'heap_allocated' will not be reliable from now on!

I see these messages after sending an device twin update or telemetry to my IoTHub.

I've located all the calls to free() in my application code, but I suspect that the Azure Sphere SDK libraries are calling free() and it's not obvious to me how to extend the heap tracker functionality to the Azure Sphere libraries.

Thanks!

[gtrevi]

Hi @bawilless, thank you for the feedback!

RE: warnings logs, your assumption is correct: by design, the GNU function wrapping applies to the user code and linked static libraries, it cannot apply within libraries that are embedded in the OS image or not linked to your App's executable.

Because from within the free() function itself the caller cannot be determined, unfortunately the wrapped-free-function can't intercept i.e. OS calls and ignore them. That is the reason for that log and the existence of the special _free() function.

Although, if the caller of the native free() is actually freeing memory that was not allocated by your App, that warning can be ignored and just seen as a heads-up; instead, in case your App did own that pointer being logged, then that would be something you want to make sure to account, as that amount of memory being freed will not be tracked in the global heap_allocated variable.

My suggestion is that once you have insured that your App is fully using the _free() wrapper, you could eventually just comment out that log. One useful thing that log does tell though, is exactly what lead you to your assumption (i.e. the calls from outside your code), which in a debugging phase may be useful information (i.e. wither a pointer is being freed for you already by external libraries).

We'll consider this valuable feedback in improving the library. Stay tuned! ;)

[gtrevi]

Closing this as feedback is taken.

One more thing, starting from OS 21.07, heap memory tracking now detail separately the heap used by shared libraries:

https://docs.microsoft.com/azure-sphere/app-development/application-memory-usage#add-heap-memory-allocation-tracking