Memory deallocation exception when using free()

Question

I am currently working on a project that requires some allocation and deallocation of large arrays on a PIC32MX775. I have a dedicated heap memory size of 1500 bytes, which should be more than sufficient and I have previously had the system allocating and deallocating memory correctly when using standard float types. However, I have recently introduced a new variable type:

typedef struct{
char index;
float gain;
float freq;   }RM_EQ_SORT_ELEMENT;

With this replacing three separate arrays I have had problems deallocating the memory using the 'free()' function ever since. An example of the arrays and how I'm trying to free them is below:

float* freq = (float*)malloc(NO_OF_FREQS*sizeof(float)); // For the unsorted average frequency
RM_EQ_SORT_ELEMENT* sortArray = (RM_EQ_SORT_ELEMENT*)malloc(NO_OF_FREQS*sizeof(RM_EQ_SORT_ELEMENT));

//**Some more code here that uses the arrays**

if(freq != NULL){
   free(freq);
}

if(sortArray != NULL){
   free(sortArray);
}

Whilst debugging, the code will jump into the 'excep_bp' loop found at the bottom of the included exceptions.c file, when the PIC32 hits either of the above free statements. If their order is changed the same result occurs.

Are there any common problems that might occur when deallocating memory like this with a PIC32? Also I understand that I might be able to debug this problem more thoroughly, any advice on what to do in this situation would help.

Answer 1

It is possible that when you added the new data type to your arrays of allocated data that its increased size is exposing an off-by-one error in your code. If by chance you are accessing an array by one too many elements there is a good chance that you are corrupting the header(s) that the heap manager puts in between MALLOCed blocks. When FREE comes along and depends in this header information to be correct all nature of things can go wrong when it is corrupted.

When you had the smaller item size in your arrays you may still have had the off by one error but the MALLOC headers may not have been getting corrupted in an immediately harmful way.

There are also compiler specific ways that the heap manager routines work. It is possible that in some cases the manager may allocate space in certain minimum number of byte sized blocks. It is just possible that in your simpler case that appeared to work that there was unused block space in the MALLOC area that was swallowing up your smaller sized off by one error without harm. When you come with a greater element size maybe the heap manager is not being so kind to you.