malloc throwing exception in library

Jay,

How do you know you are getting an assertion?  The line 270 of HeapMem.c is not an assertion.  It looks to me like you have a bad de-reference of a pointer which maybe causing an exception.  The code is doing a size check so I'm not sure why it would get into this line because line 234 checks whether there is enough memory.

Is the malloc supposed to fail because you are trying to malloc more memory than is available in the heap?

Judah

Judah,

Sorry, assertion was the wrong word:  I should say I am getting an exception there instead of an assertion, and I trace it to that line by setting the PC, SP, and LR registers to the values reported in the exception result.   I expect it is a bad pointer de-reference, but the fundamental question is:  why do we get an exception when calling malloc with a huge number from a library, but get a NULL (and a print out) when calling from the main application.   I can't think of any reason this would be the case, unless there is some macro magic going on with the "malloc" call.

And yes, I have some third party software that in some situations will end up requesting more memory than is available on the heap, and malloc MUST return NULL in that case.  Basically, it is a flash file system, and if the flash has been written with arbitrary data it reads in a "number of sectors" from the flash and allocates memory based on that read in number.   In this particular case we read in a large number of sectors (in the billions), and call malloc to build an access table, and I need it to fail in a "POSIX compliant" way, i.e. return NULL, NOT bring down the whole application by throwing an exception.   Before I "disabled" assertions, I was getting an assertion failure which brought down the system in this case.   Now I am just crashing the system with an exception when calling malloc with a too large value from any library (I've tried it in two separate ones), even though the "correct" behavior happens when calling from code in the executable project.  

  Jay

Well, I was able to work around my problem.  My third party library allows me to provide my "own" malloc, which I defined as

#include <stdlib.h>
#include <xdc/runtime/Memory.h>

void *FsMalloc(size_t size)
{
  Memory_Stats stats;

  /* first sanity check the size */
  Memory_getStats(NULL, &stats);
  if (stats.totalSize < size) {
    return NULL;
  }

  return malloc(size);
}

Several notes on this

1. I would like to request that this check be put into the standard HeapMem_alloc.   This would solve the bug (that is for sure there right now) of having a malloc(0xFFFFFFFF) successfully return a small buffer because 0xFFFFFFFF+(sizeof(header)) silently wraps around to sizeof(header)-1.
2. I noticed in implementing this that I HAD to use stats.totalSize, because by the time I got to my library calls, stats.totalFreeSize and stats.largestFreeSize were both "negative", and since these are unsigned numbers that means they were in the billions.   This is why when I requested a huge number the malloc died, because it thought it had the space according to these statistics. 

Even though I've gotten a workaround that suffices for me, I would like to pursue understanding how the internal bookkeeping got messed up in HeapMem so that a) I can fix my code and b) you can make SYSBIOS more robust to whatever stupid thing I did.   Do you have any suggestions for proceeding?

I tracked down the problem:  it turns out part of our code was needlessly stomping on that area of memory, leading to the heap bookkeeping corruption, and luckily (or unluckily, depending on how you look at it), the ONLY time this caused a problem was when too much memory was requested from the heap and the heap allocator happily went on and tried to get unmapped memory (because it thought it had BILLIONS of bytes left to allocate).

Adding a sanity check to the heap allocator to make it more robust (and fix the malloc(0xFFFFFFFF) issue) is still a good idea though, IMO.

Thanks,

    Jay