Hi,
At the beginning of the execution of my program, there was no problem, and then it suddenly stuck in heap4.c Line 292, namely configASSERT( ( pxLink->xBlockSize & xBlockAllocatedBit ) != 0 );; My malloc and free appear in pairs. How should I solve this problem?
urgent
Did you define configASSERT , enabled stack overflow checking for development/debugging ?
I think it’s either an unbalanced alloc/free even it’s doesn’t look like that at the first place or an other memory corruption caused by stack overflow or an application buffer flow/overwrite in your code.
There is no silver bullet - I afraid you have to double or triple check your code in case your provided stacks are sufficient.
Yes, I defined it.
#define configASSERT( x ) if( ( x ) == 0 ) { taskDISABLE_INTERRUPTS(); for( ;; ); }
I checked that the stack did not overflow. In my code, memory malloc and free are frequently performed.
Then you should check the usage of the allocated buffers regarding overwrites.
In my code, every time data comes, I malloc a new memory to store, and then put it into the queue. When the queue is consumed, I will only free this new memory. How do I check buffer usage?
Maybe you get an idea inspecting the memory dump before the damaged buffer assuming that the (hidden) heap management header of buffer was damaged by storing too much data exceeding the allocated size into the buffer taken from heap right before the affected one. Or re-read your code very carefully to verify that you (or a DMA transfer ?) never ever exceed the buffer size when storing data into the buffers.
1 Like
One possible source of error would be writing outside the memory of an allocation, and clobbering an allocation link in the heap.
Depending on what processor you’re using, you might be able to use this technique: Cortex-M – Debugging runtime memory corruption – M0AGX “Cortex-M3 and M4 cores have a DWT unit.” You could try setting a Debug Watchpoint on the buffer that gets damaged, which should trigger a DebugMonitor exception when it gets clobbered.