FreeLists / haiku-development / [haiku-development] Re: Latest changes and general status.

["Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>]

"Bruno G. Albuquerque" <bga@xxxxxxxxxxxxx> wrote:
> 1 - We still have memory problems. Either we are incorrectly tracking
> free/allocated memory or we are leaking memory at a very basic level. 
> Even
> unzipping files, which was supposed to use a relativelly constant 
> amount
> of memory when being executed, seems to leak around 500 Kb/s when
> unzipping the Haiku tree inside itself. The memory is not reclaimed 
> after
> it runs which means that the amount of memory used when starting the 
> zip
> process is smaller than the amount after running it (I am not 
> considering
> caches here at all). The net result of this is that it is impossible 
> to
> build Haiku inside itself with less than 1.2 Gb of memory (this is 
> the
> peak memory used here when compiling). Swap file support will of 
> course
> helps with that, but I really hope we manage to track this down and 
> fix it
> before we get that running or it can mask the problem.

Actually, that doesn't have to mean anything. For example, all slabs 
are counted to normal memory as well - and that's what the block cache 
is using. Since the slabs are deallocated lazily, the memory is not 
freed when it could be freed, but only when someone needs to free it 
(ie. when memory is low).
So while we need a better mechanism to track committed vs. cached 
memory (the slab is tricky, though, as one might not be able to flush 
all of them even under memory pressure when some blocks are still in 
use), it doesn't necessarily mean there is a memory leak somewhere.

Anyway, I think there is actually a leak in the network stack (or 
rather, TCP), but unzipping anything surely shouldn't trigger it :-)

To see where the memory is spent on, you can dig in the KDL a bit, the 
area/heap debugger commands are surely helpful with that.

Bye,
   Axel.