Ok, I will try that.
If I enable stackchecking should this kind of stack overrun be catched?
Probably. The assertion output should should the stack usage of every
active task in that case.
There are lots of ways that memory corruption can occur. Stack overrun
is just one common cause.
Ok, I will try that.
If I enable stackchecking should this kind of stack overrun be catched?
On Sun, Jun 21, 2020, at 14:22, Gregory Nutt wrote:
>
> > The most common cause... in fact the only cause that I am aware of ...
> > for heap failure is memory corruption.
>
> And a very common cause
The most common cause... in fact the only cause that I am aware of ...
for heap failure is memory corruption.
And a very common cause of heap memory corruption is a task that has
overrun its stack and clobber the meta data at the beginning of the next
chunk.
A simple thing you can do is
I'm having a weird bug appear during boot. It is being triggered at
the first call of mm_free which comes from a call to mtdconfig driver.
I have enabled debug information and I'm also debugging at the point
before crash but since I don't understand the memory manager I can't
tell where
