[Barrelfish-users] Bug in malloc()/free() ?

[Simon Peter]

Unfortunately, no. free() doesn't explicitly call the memory server to 
give back memory. Instead, the kernel tracks capabilities and knows when 
the last copy of a capability that's backed by memory goes away and will 
re-create a RAM capability to the memory server.

Simon

On 27.09.2011 14:00, Zeus Gómez Marmolejo wrote:
> I am wondering how the malloc() finally ends up calling the memory
> server but free() doesn't. Could it be this??
>
> El 25 de septiembre de 2011 16:03, Simon Peter <speter at inf.ethz.ch
> <mailto:speter at inf.ethz.ch>> escribió:
>
>         Thanks for the patch. Now it takes a bit longer ... but it ends
>         up by
>         returning NULL anyway. The above program didn't change.
>
>          > spawnd.0: spawning /x86_64/sbin/myapp on core 0
>         myapp.0 in main() ../barrelfish/usr/tests/myapp/__myapp.c:12
>         malloc() returned NULL at 30710
>         Aborted
>
>
>     I didn't see this happening when I was testing, but maybe I didn't
>     wait for long enough. I'm going to look at it again.
>
>
>         To add originality to the situation, sometimes I get this error too:
>         ERROR: mem_serv.0 in mem_lmp_default_error_handler(__)
>         ./x86_64/lib/barrelfish/_for___lib_barrelfish/mem_flounder___bindings.c:1328
>         ERROR: asynchronous error in Flounder-generated mem lmp binding
>         (default
>         handler)
>         Failure: ( libbarrelfish) Failure in lmp_chan_alloc_recv_slot()
>         [LIB_ERR_LMP_ALLOC_RECV_SLOT]
>         Failure: ( libbarrelfish) Failure in slot_alloc()
>         [LIB_ERR_SLOT_ALLOC]
>         Failure: ( libbarrelfish) Failure in cnode_create()
>         [LIB_ERR_CNODE_CREATE]
>         Failure: ( libbarrelfish) Failure in ram_alloc() [LIB_ERR_RAM_ALLOC]
>         Failure: ( libmm) No matching node found [MM_ERR_NOT_FOUND]
>         Aborted
>
>
>     In both cases, the root cause is the same: You're running out of
>     memory. Here, when allocating a new receive slot in the memory
>     server itself. Unfortunately, a lot of the memory management code is
>     very fragile and rather stops the system, instead of failing more
>     gracefully, when you're running out of memory.
>
>
>         To give you some hints about the first error, it fails when
>         calling to
>         vspace_mmu_aware_map() in morecore.c:59 with error
>         LIB_ERR_FRAME_CREATE_MS___CONSTRAINTS. It turns out that (step <
>         BASE_PAGE_SIZE). As this is the first call to that function in
>         the loop,
>         the buffer is NULL.
>         As I see, in the latest version the debug_err() has been removed
>         when
>         reaching this condition.
>
>
>     That sounds correct. The algorithm in morecore_alloc() tries to
>     allocate successively smaller pieces of memory when the original
>     request did not succeed. In this case, it was already completely out
>     of memory on the first try and gave up.
>
>     Simon
>
>
>
>
> --
> Zeus Gómez Marmolejo
> Barcelona Supercomputing Center
> PhD student
> http://www.bsc.es
>
>