One possibility is that you are not properly harvesting thread or child
exit status. That is not a memory leak exactly. You have to start
threads in a detached state to prevent the return status from collected.
Could something like that be happening?
On 1/23/2024 2:45 AM, yfliu2008 wrote:
Geogory,
The leak happens to the kernel side, not to apps side. As with PROTECTED or KERNEL build, it is the "used
Kmem" keeps growing, where the "used Umem" don't grow. As FLAT mode has only "Umem" so
it grows in FLAT mode.
I don't know how to instrument ostest yet. With the help of "echo used >
/proc/memdump", I can see used memory nodes list added.
If needed I can create a Github ticket to track this so that some experts can
reveal the root cause later.
Regards,
yf
Original
From:"Gregory Nutt"< spudan...@gmail.com >;
Date:2024/1/19 22:07
To:"dev"< dev@nuttx.apache.org >;
Subject:Re: observations on kernel memory
There is instrumentation in ostest that prints heap usage after each
test test. That should isolate the memory leak.
On 1/19/2024 2:07 AM, yfliu2008 wrote:
> Dear experts,
>
>
>
>
> With "rv-virt/knsh32", I noticed the "used Kmem" shown by "free" command keeps
growing after each run of "ostest", below is numbers I recorded during five runs:
>
>
>
>
>
> 10652 12756 12804 12852 12900 12948
>
>
>
>
> The first number is taken after boot, other numbers are taken after running
"ostest" once. Except for the increasion of the first run, increasion of other runs
is about 48 bytes, though not big but it may eventually lead to crash.
>
>
>
>
> Similar observations can be got from "rv-virt/nsh", "canmv230/knsh",
"canmv230/pnsh" etc.
>
>
>
>
>
> Is this a known behavior?
>
>
>
>
>
> Regards,
>
> yf
