malloc/free is there a way to see if all match?
I am exposed to this project where malloc is liberally spread all over the place and wonder if memory get freed up in all cases. I would hate to see that, after a month of usage the thing blew up. A very subtle error in this respect would never show up during development where the program is reloaded many times a day, whereas at a customer where a reset may be a yearly event a small error in this respect would show up eventually.
Erik
... for detecting so-called "memory leaks"
More common for "desktop" stuff, admittedly.
You could (should?) instrument your malloc and free so that you can observe...
I am exposed to this project where malloc is liberally spread all over the place and wonder if memory get freed up in all cases. I would hate to see that, after a month of usage the thing blew up.
Unfortunately even complete absence of such mismatches (a.k.a. memory leaks) doesn't really solve the problem. There's that nasty effect called heap fragmentation that will cause allocatio requestes to fail even though the total size of free memory would be sufficient to satisfy them.
The only sane approach for truly embedded systems that are expected to run indefinitely is to only use malloc() during start-up, and never free() at all --- and make sure that there's enough memory for those malloc()s in every allowed configuration.
Wrap them and keep track of the allocation and release, you can start at a simple level with counting, or extend to tracking which don't get released, or if things get multiply released. This kind of thing will require additional foot prints for the allocation, and maintaining lists. Would suggest allowing for gradation of the level of tracking at compile time depending if it's merely accounting for things, or chasing down specific problems.
The bigger problem with long term use is the fragmentation/fracturing of the memory pool, where there is enough memory, just not contiguous. A list of current allocation might permit you to map that.
You can replace all calls to malloc/free with your own implementation that keeps track of things. You can find inspiration in some of the memory managers made available via FreeRTOS. The advantage here is that you can take measures of allocation fails - you are in total control.
For embedded use, it is often advantageous to create heaps of different-sized blocks, where the program may be able to allocate max M blocks of size 128 byte, max N blocks of size 512 byte, ...
This is basically the strategy used by RTX.
With pool of fixed-size objects, there can't be any fragmentation. The disadvantage is that a pool can have lots of free space, while a pool of different-sized objects can have all objects already allocated.