After enlarging the stack size of "AppBringUp" thread, the remote node can boot NSH
on RPMSGFS now. I am sorry for not trying this earlier. I was browsing the "rpmsgfs.c"
blindly and noticed a few auto variables defined in the stack... then I thought it might worth a try so
I did it.
That is good news! I usually try increasing stack sizes first thing.
Because it it easy to do and by far the most common cause of memory
corruption.
Is this a configuration option? If not, it should be.
Now I am still unclear about why small stack leads to heap corruption? Also how we
can read this stack issue from stackdump logs? Let me know if you have
any hints.
For a kernel thread, the stack is allocated on the heap. When you
overrun the stack, the metadata at the end of stack allocation may be
clobbered. My confusing, the meta data or actual data of of the
preceding (victim) chunk may be corrupted. Often the the symptoms of
the failure are even more obscure than these.
