Products > Programming

Heap analysis tool for embedded systems

(1/4) > >>

peter-h:
Some context is here
https://www.eevblog.com/forum/programming/best-thread-safe-printf-and-why-does-printf-need-the-heap-for-f-etc/

There are tools out there but mostly irrelevant stuff for Java etc.

It seems obvious that any such tool must be totally specific to the heap code you are using. My project uses a heap which came in the ST Cube supplied libc.a library (no source provided).

When I do a malloc I get the address of the allocated block (or NULL) which is a kind of handle to the block, but to work back to where the calling code is, you would need to capture the address of the code calling malloc() and them somehow work back through the symbol table, to produce a list of C functions and how much heap each one owns.

Or one could step through the heap and compile a list of allocated blocks but without knowing who has which one.

Where does heap code store the list of blocks? Does it malloc that as well? :)

SiliconWizard:
The easiest approach for heap allocation analysis is to wrap heap management functions (malloc, calloc, free...) in custom functions (usually by defining macros that will override them) than can trace heap use in the manner that is most relevant for you. It's not hard to do. But there are ready-made solutions for this (such as Valgrind) - thing is, most of them are not very lightweight or may need a hosted environment, so they aren't ideal for MCUs. But rolling your own according to your own needs is not rocket science and would be a nice addition to your toolset.

That can be implemented in, for instance, a single header file that you'd include *after* any standard header.
The idea would look like:

--- Code: ---#ifdef HEAP_TRACE

#undef malloc
#define malloc(size)    myTraceMalloc(size, __LINE__, __FILE__)

(...)

static inline void * myTraceMalloc(size_t size, int line, const char *fileName)
{
(...)
}

(...)

#endif

--- End code ---

eutectique:
You might want to try Fortify library by Simon Bullen. It is doing exactly what SiliconWizard suggested, but has rather little overhead. One of the places to get it: https://ftp.fau.de/aminet/dev/c/fortify22.lha

As I can see, the version there is from 1995. I've got a version from 2008, attached.

eutectique:
Googled a bit more, the only place with the latest version of Fortify is http://svn.netlabs.org/repos/fm2/trunk/dll

Sherlock Holmes:

--- Quote from: peter-h on August 14, 2022, 12:00:14 pm ---Some context is here
https://www.eevblog.com/forum/programming/best-thread-safe-printf-and-why-does-printf-need-the-heap-for-f-etc/

There are tools out there but mostly irrelevant stuff for Java etc.

It seems obvious that any such tool must be totally specific to the heap code you are using. My project uses a heap which came in the ST Cube supplied libc.a library (no source provided).

When I do a malloc I get the address of the allocated block (or NULL) which is a kind of handle to the block, but to work back to where the calling code is, you would need to capture the address of the code calling malloc() and them somehow work back through the symbol table, to produce a list of C functions and how much heap each one owns.

Or one could step through the heap and compile a list of allocated blocks but without knowing who has which one.

Where does heap code store the list of blocks? Does it malloc that as well? :)

--- End quote ---

I designed and wrote a concurrent and persistent heap manager some years back, for Windows. One could persist the heap as a disk image file (and thus restore complex state from that image). Anyway that has a diagnostic system built in as part of the design. One could have the heap automatically run a validation of all metadata before each allocate and before each free, yes it would crawl when one did that but it would almost always discover corruption and get one quite close to the cause.

I don't really know the algorithms used by C and I guess they are not part of the standard, so how to validate a C heap is an interesting question.

There was also a tagging option, one could pass a simply 4 char tag code into the allocate calls, that would let you track back which bit of code allocated which blocks, this was done in functional areas not with ever tag being different (i.e. you might have tags like 'INTH' for interrupt handlers or 'IOBF' for code that allocates buffer for IO and so on.

The tagging can be done easily by you too, you just allocate a special struct on top of what the "user" wants to allocate. But though this is useful the real culprits of heap corruption is code over writing metadata or other already allocated user data.

Sometimes one can test a system with randomized inputs and let it run, doing a validation call on ever allocate/free, if you can generate a repeatable failure (that is, use repeatable random values) like that you're well on the way to fixing it.

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod