Recently I ran into a memory leak, and I was not able to trace the exact origin of this leak due to a closed source part. To be able to find the cause of this I modified heap4.c and task.c/h, to store the amount of data allocated and freed per thread, so I could pinpoint the offending thread.
Attached is the modification I used for this, where I added a configuration variable (configUSE_MALLOC_TRACE) that enables some extra storage in the TCB. In this extra storage (2 64-bit counters) the amount of allocated and freed memory is stored. By substracting these it is possible to determine the amount of storage a thread has still claimed (or leaked).
When pvPortMalloc is called the memoryAllocated variable is increased with the requested amount, when vPortFree is called memoryFreed is increased with the amount read from the heap administration.
This mechanism only works if the malloc and free are executed from the same thread, when passing data between threads this does not work as the allocated counter would be increased for one thread and the free counter for another thread. This would result in one thread with a huge amount of allocated data and another with a negative amount.This could be solved by adding a thread-ID to each alloc, but this would mean quite a lot of extra overhead in the heap-administration.
Also allocating from outside threads is not logged.
