Possible block cache memory leak

[anevilyak]

On a system with 1GB of RAM, I successfully managed a complete checkout of the Haiku source tree from within Haiku in a single session. However, by the time it was done, there was ~90MB of RAM free, most of it being consumed by the kernel. A quick glance at listarea indicated around 3000 block cache areas, so I'm wondering if this is possibly a leak. Leaving the sys alone for a while, doing a sync, etc. did nothing to decrease the mem usage or area count. This was on hrev23962.

[axeld]

The ultimate check would be to have done these things on a different volume than the boot volume, and then unmount it. Unless there is any memory pressure, the block cache will not free up any memory.

[bbjimmy]

Replying to axeld:

The ultimate check would be to have done these things on a different volume than the boot volume, and then unmount it. Unless there is any memory pressure, the block cache will not free up any memory.

I am sure I am looking at the same issue.

Performing:

jam -q

...patience...

...patience...

...patience...

...found 67858 target(s)...

...updating 6981 target(s)...

InitScript1 generated/haiku.image-init-vars

vfork: Out of memory

running hrev26389

I have only 448 MB of ram.

I performed the jam on an svn checkout that resides on a different partition.

Before the jam, 19% was used.

The memory used peaked at 89%

After the jam error, there was 49% still used ... mostly in System Resources & Cashes according to the ProcessController app.

After dismounting the volume that contained the haiku source tree, I was back to 19% used.

It seems that the issue is not a memory leak, but there is still an issue. This same computer can jam the haiku image from two trees at the same time using Ubuntu Linux, but I am unable to build Haiku within Haiku.

[anevilyak]

This in fact a duplicate of 2046, on which much more information can be found. Closing this one.