On 3/12/2024 5:12 AM, Nathan Hartman wrote:
Try Alan's suggestion to use stack monitor, and that will help understand
if there is something wrong. (If it shows that old stack size was OK, while
we know corruption was happening, then we will know to look for some out of
bound write.)
Does the stac
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
On 3/12/2024 1:10 AM, yfliu2008 wrote:
On the other hand, if we choose not mounting NSH from the RPMSGFS, it can boot
smoothly and after boot we can manually mount the RPMSGFS for playing.
That sounds like an initialization sequencing problem. Perhaps
something is getting used before it has be
ruption?
> > Also how we can read this stack issue from stackdump logs? Let
> me
> > know if you have any hints.
> >
> >
> > Regards,
> > yf
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
tack leads to heap corruption?
> Also how we can read this stack issue from stackdump logs? Let me
> know if you have any hints.
>
>
> Regards,
> yf
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Original
>
>
>
> From
e can read this stack issue from stackdump logs? Let me
> know if you have any hints.
>
>
> Regards,
> yf
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Original
>
>
>
> From:"yfliu2008"< yfliu2...@qq.com >;
>
>
use it yet.
Regards,
yf
Original
From:"Gregory Nutt"< spudan...@gmail.com >;
Date:2024/3/11 1:43
To:"dev"< dev@nuttx.apache.org >;
Subject:Re: mm/mm_heap assertion error
On 3/10/2024 4:38 AM, yfliu2008 wrote:
> Dear experts,
>
>
>
>
>
fyid=0,
> >>> rsc=0x80200050, rsc_io=0x7080408 priv=0x708ecd8,
> >>> notify=0x704e6d2 rst_cb=0x0)
> >>> at open-amp/lib/remoteproc/remoteproc_virtio.c:356
> >>> #6 0x0704e956 in remoteproc_create_virtio
> (rproc=0x708ecd8,
> >
If the memory location that is corrupted is consistent, then you can
monitor that location to find the culprit (perhaps using debug output).
If your debugger supports it then setting a watchpoint could also
trigger a break when the corruption occurs.
Maybe you can also try disabling features
moteproc/remoteproc.c:957
> > #7 0x0704b1ee in rptun_dev_start (rproc=0x708ecd8)
> > at rptun/rptun.c:757
> > #8 0x07049ff8 in rptun_start_worker (arg=0x708eac0)
> > at rptun/rptun.c:233
> > #9 0x0704a0ac in rptun_thread (argc=3, argv=0x7
From:"Gregory Nutt"< spudan...@gmail.com >;
Date:2024/3/11 1:43
To:"dev"< dev@nuttx.apache.org >;
Subject:Re: mm/mm_heap assertion error
On 3/10/2024 4:38 AM, yfliu2008 wrote:
> Dear experts,
>
>
>
>
> When doing regression check on K230 with a previously
On 3/10/2024 4:38 AM, yfliu2008 wrote:
Dear experts,
When doing regression check on K230 with a previously working Kernel mode
configuration, I got assertion error like below:
#0 _assert (filename=0x704c598 "mm_heap/mm_malloc.c", linenum=245, msg=0x0,regs=0x7082730
This does indicate
12 matches
Mail list logo
