The software I am working on is written in c++ and uses the RTX RTOS. The program creates instances of module classes according to a configuration string. These are deleted and then remade if this string is altered.
After a few iterations the program hangs during a call to new which I am assuming is because it ran out of heap space. What I would like to do is monitor the amount of heap available and check that modules free all the memory they are allocated when they are deleted.
Could anyone offer some advice on detecting memory leaks or a method of monitoring the heap usuage?
Many Thanks
not a big expert (yet) when it comes to ARM / MCBSTR, but maybe you have the source code of your memory manager? I guess your 'new' function is overloaded so that it gets the chuncks of memory that are required from a pool that is allocated during start-up. if you have access to the source, you can monitor everything you want. I am not sure there is another way that is relialbe (i.e. answering the question: "hmmm, the memory pointed by this pointer was allocated on the stack or the hear?")
what about RTX? doesn't it have a memory manager?
It has a memory manager for fixed-size objects. For variable-sized objects, the normal runtime library functions must be used.
Info from http://www.keil.com/support/man/docs/rlarm/rlarm_ar_mbx_using.htm
"The fixed block memory allocation functions are fully reentrant. The variable length memory allocation functions are not reentrant. Therefore the system timer interrupts need to be disabled during the execution of the malloc() or free() function. Function tsk_lock() disables timer interrupts and function tsk_unlock() enables timer interrupts."
you can always override new to add some logging...
Continuous allocation and deallocation of dynamic memory causes the heap to become fragmented. That could be reason of hang in the operator new. RTX RTOS don't have background garbage collector and better way here is use static objects.
Depending on the age and conformity of your compiler, new should throw an exception or return null when it runs out of memory. Are you handling these conditions? The code should only hang if you ignore the out-of-memory condition.
To find the leaker, add some overhead to the allocated memory to store the allocator. #define a macro to pass __FILE__ and __LINE__ down through new. (You might find it more convenient to substitute other ID information.) Run the program for a while. Then, dump the heap and see who allocated all of the currently-allocated blocks. That should tell you who was responsible for deallocating that block, but didn't.
If you think someone's corrupting the heap, you can similarly add guard fields before and after the allocated block, write well-known patterns there, and check to be sure they're undamaged on deallocation (and even periodically if you wish).
For your most heavily created and destroyed objects, it'll probably be worthwhile creating a fixed-size memory pool for those objects. Faster operation and no fragmentation.
You can show the heap statistics with __heapstats((__heapprt)fprintf, stderr );
Eugen