Hi there,
Is there a way to re-initialize the whole heap region? It should also reset "internal pointer" of the malloc method. I use malloc/free in only one task and I want to start/stop this task. This should prevent memory leaks.
Chip: Cortex M3, LPC1788
Thx, Frederic
Sounds like a very dangerous thing to do while program is fully operational. Are you sure no 3rd party component uses the heap? In my opinion, it is better to watchdog reset than to risk undefined/unpredictable behavior.
A large number of malloc/free problems occur when the user is over zealous in using 'free' and attempts to free memory not allocated and that demands a reset.
Be very careful of malloc/free.
Bradford
At the moment I'm doing a reset of the device to make the free-all. It works fine, but it's not so "nice". Still I think I will stick to that solution at the moment.
Since this isn't only my code, free() isn't used for each malloc(). Theoretically, if I manage to free() every malloc(), will the state be the same as after a re-initialization?
Frederic
To answer your question: Yes. That the idea. Of course the RAM dedicated to the heap will not be 0, but it will be empty. Why not spend some time to find the root cause, i.e the memory leak?
Theoretically, if I manage to free() every malloc(), will the state be the same as after a re-initialization?
The answer to that is it might. It totally depends upon the implementation of malloc() and free(). It might keep the internal list of previous allocations intact and therefore might still be fragmented, thus it might not be able to allocate a large block. We have certainly witnessed some heap allocation strategies that work in this manner.
"If you don't manage to free memory in exactly the reverse order that it was allocated, you might end up in a fragmented memory and after n times you might fail to allocate enough contiguous memory." Is this statement absolutely true? There are some embedded applications build around very complex SW architectures and they just can't get away with using malloc/free. So, an statement like this may bring down everything. I'm talking about the work made by many engineers over years of work, it would all fall apart if this statement is true. Is there anybody from ARM who could assist in this thread? We're working on a case where free/malloc result in data aborts. We've traced the code up the moment when free is called. We can capture the memory state in that moments and see that the pointers exist and the data pointed is in the right place, everything seems ok, there'r no other pieces of code running, tasks are locked in RL so they can't interrupt, yet the next instruction (free(pointer)) results in a data abort exception.