Heap analysis tool for embedded systems

[peter-h]

Am I right that the line
   if (heap_end == 0)
should be
   if (heap_end == NULL)

I know that generally NULL is same as 0.

ISTM that if in this heap implementation you allocate 100 blocks, and free one of these, this involves stepping through the whole lot until the address matches the free() parameter. Reading the sourcecode of the heap, they are quite concerned about how long _sbrk takes to execute and use some complicated strategy to call it as infrequently as possible, but _sbrk is trivial compared to the foregoing search.

It should not be too hard to write a tool which displays the heap usage, by stepping through the list and, for each block found, look up its address in the .map file to get the symbol name.

BTW (from my internal doc):

The suggested candidate source code for the ST Cube IDE lib malloc
https://github.com/devkitPro/newlib/blob/master/newlib/libc/stdlib/_mallocr.c
appears to not be the one (unless fixed since) because the problem described here
https://stackoverflow.com/questions/39088598/malloc-in-newlib-does-it-waste-memory-after-one-big-failure-allocation/76138157#76138157
(which does refer to the above source, looking at various spot checks) is not present in ours. A malloc of > heap space fails but subsequent reduced mallocs work fine. A more likely candidate sourcecode is this “nano”
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdlib/nano-mallocr.c;h=13b72c99ffd7007b53c2e3270a56da237857742a;hb=HEAD
but this has another issue:
https://www.eevblog.com/forum/programming/help-needed-with-some-heap-test-code/msg4838741/#msg4838741
the conditions for which remain to be clarified.

[ejeffrey]

Am I right that the line
   if (heap_end == 0)
should be
   if (heap_end == NULL)

They are exactly the same per the C standard.  I personally always use 0 for null pointer initialization and checks, I never use NULL.

ISTM that if in this heap implementation you allocate 100 blocks, and free one of these, this involves stepping through the whole lot until the address matches the free() parameter. Reading the sourcecode of the heap, they are quite concerned about how long _sbrk takes to execute and use some complicated strategy to call it as infrequently as possible, but _sbrk is trivial compared to the foregoing search.

On systems with virtual memory getting memory with sbrk can be expensive because it involves interacting with the OS memory manager and mapping new pages into your address space, including TLB flushes.  On a microcontroller its very cheap but an extremely limited resource.  That's why it's important to check the freelist for suitable chunks before calling sbrk.

[peter-h]

Thank you.

I moved on to this
https://www.eevblog.com/forum/programming/help-needed-with-some-heap-test-code/

and wonder if I am doing something wrong...

[SiliconWizard]

Am I right that the line
   if (heap_end == 0)
should be
   if (heap_end == NULL)

They are exactly the same per the C standard.  I personally always use 0 for null pointer initialization and checks, I never use NULL.

NULL is pretty "idiomatic" C, while 0 is more idiomatic to C++. Just curious, do you maybe have a C++ background? Just a detail.

Otherwise yes, 0 for a pointer is a null pointer in C, but I don't remember at what point it became so in the standard, I'd have to check back the history. Not convinced it was always the case.

That can be pretty confusing to some people though, so I personally don't recommend using '0'. Here is why:

0 can be used as a null pointer in C (again, don't know for sure if it was always the case in the past, or if it was borrowed from C++ as many 'new' features in C), but of course it doesn't imply that a null pointer has actually a value of zero behind the scenes, and that's what can confuse many people, even if you personally may just see it as an abstraction and don't care.

NULL has the benefit of being more "neutral" in terms of abstraction, IMHO.

One thing that can confuse people further is when it comes to casting from/to integers. As the '0' pointer may not be zero, if you cast a zero pointer to an integer, what do you get?
Given there are nasty (IMHO) implicit conversions in C all over the place, can there be nasty consequences? Maybe. Or maybe not. I know the C standard fairly well, and though I wouldn't bet a lot on this particular point without digging into the standard again.

Fear not, C23 solves it all and brings 'nullptr', which, this time, is a true pointer in terms of type, which removes any possible ambiguity with '0'.
But as a new feature, this in turn may confuse old -timers.
And given that even C99, which is 24 years old, is still not fully used by many C developers, maybe C23 will start being widely used in 2100, or something.
Oh well.

 

[peter-h]

do you maybe have a C++ background

No. No interest in complicated stuff I've done loads of asm, a bit of Pascal, Fortran, Basic many years ago. Last 2-3 years just loads of C but avoiding stuff like pointers.

It was drummed into me by a colleague (much better C coder than I will ever be) to use NULL because it a clearer way of denoting a null pointer, and in theory NULL might not be a zero int value in some implementations (probably none exist though).

[peter-h]

Back on the original topic.
Comparing three similar but not identical sources

https://github.com/devkitPro/newlib/blob/master/newlib/libc/stdlib/_mallocr.c
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdlib/nano-mallocr.c;h=13b72c99ffd7007b53c2e3270a56da237857742a;hb=HEAD
https://sourceware.org/git/?p=newlib-cygwin.git;a=blob_plain;f=newlib/libc/stdlib/nano-mallocr.c;hb=HEAD

Last two are very similar. The 1st one is something else.

The 1st one contains this comment which the ST heap indeed does

When a chunk is freed, 12 (for 4byte ptrs) or 20 (for 8 byte
       ptrs but 4 byte size) or 24 (for 8/8) additional bytes are
       needed; 4 ( 8 ) for a trailing size field
       and 8 (16) bytes for free list pointers. Thus, the minimum
       allocatable size is 16/24/32 bytes.
       Even a request for zero bytes (i.e., malloc(0)) returns a
       pointer to something of the minimum allocatable size.

malloc(0) allocates 16 bytes.

Anyway, all three have a function malloc_stats() which gives you basically what I asked for!

It just has not been compiled into the ST code... that symbol is nowhere to be seen.

I am unable to take this further due to the vast number of build options and dependencies. ST never released the build options they used for libc.a / stdlib.

But I think it is the 1st one they used.