[Barrelfish-users] Bug in malloc()/free() ?
speter at inf.ethz.ch
Sun Sep 25 16:03:44 CEST 2011
> 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
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()
> ERROR: asynchronous error in Flounder-generated mem lmp binding (default
> Failure: ( libbarrelfish) Failure in lmp_chan_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]
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.
More information about the Barrelfish-users