When does malloc return NULL in a bare-metal environment?

Question

There is a c memory model as following :

      +--------+   Last Address of RAM
      | Stack  |
      |   |    |
      |   v    |
      +--------+
RAM   |        |
      |        |
      +--------+
      |   ^    |
      |   |    |
      | Heap   |
      +--------+
      |   ZI   |
      +--------+
      |   RW   |  
      +========+  First Address of RAM

The stack and heap space increase in opposite directions. They would be overlapped with each other in the middle. So my questions are:

In a bare-metal environment, when does malloc return NULL?
In a bare-metal environment, how to prevent stack from overlapping with heap?

In a bare-metal environment, it's usually best not to use `malloc` at all. Instead, use memory pools that manage a fixed number of fixed-size memory blocks. — user3386109, Aug 24 '16 at 03:39
In a bare-metal environment, `malloc` often doesn't exist. If it does exist, then check the documentation for wherever it came from. — user253751, Aug 24 '16 at 03:40
Also, that "C memory model" has not been correct for over two decades. — user253751, Aug 24 '16 at 03:41
"when does malloc return NULL?" --> Note that `malloc(0)` may return `NULL` and does not imply out -of memory. YMMV. — chux - Reinstate Monica, Aug 24 '16 at 04:00
@user3386109 ·malloc· is a c library function. Do you mean declare a memory pool globally ? Then you could implement your own malloc function to manage this memory pool. — lrouter, Aug 24 '16 at 05:45
Maybe [this article](https://en.wikipedia.org/wiki/Memory_pool) will help. A memory pool is a different way to manage dynamic memory. It is used instead of `malloc` on systems where `malloc` is either not available, or not suitable for use. Which would be pretty much any system that doesn't have an OS. — user3386109, Aug 24 '16 at 06:22
the link.cmd file (for TI, similar file for other environments) tells the linker exactly where to place everything in memory. One of the items that is placed is the `heap`. the link.cmd file (usually) does not say exactly where to place the `heap` but often says how large to make the `heap`. — user3629249, Aug 24 '16 at 23:51

score 3 · Answer 1 · answered Aug 24 '16 at 03:05

@WikiWang is correct if you are using a static, compile-time memory layout (edit although you have to tell your malloc implementation somehow where the end of the heap is).

If not, and assuming you mean bare-metal, it depends on the C library implementation in your board-support package. The library must provide some implementation of brk(2) or a function having a similar effect. malloc works within the area of memory set by brk or sbrk. For example, see the malloc source calling macro MORECORE, which is by default sbrk. Your C library will have to use something other than a kernel call for that :) .

score 2 · Answer 2 · answered Aug 24 '16 at 03:01

Size of stack is determinded at compile time.

      +--------+   Last Address of RAM
      | Stack  |
      |   |    |
      |   v    |
      +--------+
RAM   |        |
      +--------+   Stack Limit
      |        |
      +--------+
      |   ^    |
      |   |    |
      | Heap   |
      +--------+
      |   ZI   |
      +--------+
      |   RW   |  
      +========+  First Address of RAM

malloc return null if there is not enough space for the requested heap.

And its your duty to to prevent stack overflow!

Based on your figure, I found out a label 'heap_limit' and a stack_limit in my map file. — lrouter, Aug 24 '16 at 05:34

score 2 · Answer 3 · answered Aug 24 '16 at 03:17

when does malloc return NULL?

It may depend on C compiler and library implementation. For example, my malloc implementation calls sbrk, which is a system call in Linux environment. As we have no Linux on the MCU, I provided my own implementation of sbrk like this:

// Global variables.
extern unsigned int _heap;
extern unsigned int _eheap;
static caddr_t heap = NULL;

caddr_t _sbrk(int incr)
{
  caddr_t prevHeap;
  caddr_t nextHeap;

  if (heap == NULL) { // first allocation
    heap = (caddr_t) & _heap;
  }

  prevHeap = heap;

  // Always return data aligned on a 8 byte boundary
  nextHeap = (caddr_t) (((unsigned int) (heap + incr) + 7) & ~7);
  if (nextHeap >= (caddr_t) & _eheap) {
    errno = ENOMEM;
    return ((void*)-1); // error - no more memory
  } else {
    heap = nextHeap;
    return (caddr_t) prevHeap;
  }
}

and _eheap is defined in the linker script:

PROVIDE ( _eheap = ALIGN(ORIGIN(ram) + LENGTH(ram) - 8 ,8) );

Having this, malloc in my program will return error only when it hits the end of the memory. Stack top address is not recognized, thus I cannot diagnose possible stack corruption by checking malloc return value.

how to prevent stack from overlapping with heap?

You may define your own limit for sbrk to return error, which will prevent malloc from invading stack memory.

I have checked my map file. Yes, there is a heap limit. – lrouter Aug 24 '16 at 05:36 — lrouter, Aug 24 '16 at 05:36

score 2 · Answer 4 · answered Aug 24 '16 at 05:34

1) bare metal you probably dont want to use malloc in the first place

2) bare metal you own that memory and manage it so you are the only one that can answer the question.

3) even on not-bare-metal (windows, linux, etc) stack hitting the heap or running into the code space is not something you normally get protections from, you need to either tell the compiler, if it supports it, to add a ton more code, or you just design your software right to not collide.

What is your memory allocation scheme, what does your code do, how if at all have you told this code what space it can allocate from. If the compiler supports it at all you may need to tell the compiler the space or runtime indicate where the top of heap is currently. Or maybe the compiler relies on that space being filled with a pattern and it checks for the pattern before allocating, which means in bare metal for a case like that you would need to fill that memory with that pattern. First and foremost you need to find out if and how the compilers output works with respect to preventing the stack colliding with data or program space.

Normally you know by your system/software design how deep your stack will go worst case, and from that how much memory you have left. As you do your design and then implementation you verify the maximum stack depth, how much ram you ended up needing and making sure you have not oversubscribed the ram you have available for that processor in that system.

Bare metal there is no reason to expect the compiler nor libraries nor other tools to do this work for you.

one is by analysis of your code. Another is a valgrind type approach, fill ram with some pattern, run your program, stop and examine ram, where does the fill pattern end, how deep did the stack go. They by analysis you need to confirm you took the deepest path from a stack consumption perspective. Not doing the analysis right and relying only on experimenting you may miss a path and be off by some amount small or large. — old_timer, Aug 24 '16 at 10:54

score 1 · Answer 5 · answered Aug 24 '16 at 10:57

malloc will return NULL when the allocation fails. Usually this is due to lack of memory. In a free-running model, where heap and stack don't have limits, it would always give you memory (even if that meant colliding with the stack).

Fortunately, that is never done. Usually the heap and the stack have fixed maximum sizes, so checks are easier. For example, if the library malloc calls your sbrk (typical situation), you could write sbrk so that it refuses to extend the heap past the stack limit. This avoids the heap from colliding into the stack.

The other way around (stack collides into heap) is trickier. First off, there isn't much you can do to recover from a stack overflow, so the strategy here would be to produce useful debug info and halt the system to avoid working on corrupted memory. Technically, the compiler could add checks for every stack allocation, but that would noticeably slow down the code (I don't even know if any compiler supports it - probably yes, with some instrumentation). If your MCU has a Memory Protection Unit (MPU), you could configure a small unaccessible zone above the stack limit, so that stack overflows will generate an MPU fault. This technique is often called guard page (much like guard bytes with a memory breakpoint, if you want). For this to work, however, exceptions need to use a different stack (otherwise you're in the same boat). Note that stack canaries don't protect against stack-heap collision.

That being said, in bare metal you are the one designing the memory layout, and you can set it up however you want depending on your needs. malloc is generally frowned upon because it's non-deterministic. Also, you should profile your stack usage and know your maximum stack depth in order to properly size the stack.

@D.E.T That depends on how your libc implements it. In the most common case, it won't do it directly but it will allocate memory calling an `sbrk` you define, so you can check it there. — Andrea Biondo, Aug 26 '16 at 11:33

When does malloc return NULL in a bare-metal environment?

5 Answers5

Linked