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

Thu Sep 22 23:49:24 CEST 2011

Hi Zeus,

At the risk of asking a very naive question, 

> The program is always stopping after allocating about 1Gb of memory,
> which is the size of the physical memory of the virtual machine....

 - could this simply be a case of you running out of physical memory
(Barrelfish doesn't overcommit memory, and does not page to disk), and
Barrelfish being less than informative about the situation?

 -- Mothy

At Thu, 22 Sep 2011 19:33:49 +0200, Zeus Gómez Marmolejo <zeus.gomez at bsc.es> wrote:
> Hi Simon,
> 
> 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
> 
> 
> 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
> 
> 
> 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.
> 
> 
> Thanks for your help,
> zeus.
> 
> 
> El 22 de septiembre de 2011 16:25, Simon Peter <speter at inf.ethz.ch>escribió:
> 
> > I think I found the issue. Here's a patch:
> >
> > diff -r 215f069a289c lib/barrelfish/vspace/mmu_**aware.c
> > --- a/lib/barrelfish/vspace/mmu_**aware.c Tue Sep 20 15:18:31 2011 +0200
> > +++ b/lib/barrelfish/vspace/mmu_**aware.c Thu Sep 22 16:23:43 2011 +0200
> > @@ -227,6 +227,7 @@
> >
> >     // Reduce offset
> >     state->offset -= bytes;
> > +    state->consumed -= bytes;
> >     if (success) {
> >         state->mapoffset = min_offset;
> >     }
> >
> >  -- Simon
> >
> >
> > On 22.09.2011 13:23, Zeus Gómez Marmolejo wrote:
> >
> >> I'm running free() under the debugger and the x86_64 specific hack is
> >> not firing.
> >>
> >> It's going through lesscore() and then from a quick view it seems that
> >> is doing it ok:
> >>
> >> memobj_anon unfill(), calling to the x86_64 pmap unmap and then calling
> >> to the kernel vnode_unmap(). Finally track_frame_return()...
> >>
> >> I don't see anything wrong here, it seems it's not skipping anything...
> >> The curious thing is that the pointer returned by malloc() is always the
> >> same. So it "seems" that free is working correctly.
> >>
> >>
> >> zeus.
> >>
> >> El 22 de septiembre de 2011 01:33, Baumann Andrew <andrewb at inf.ethz.ch
> >> <mailto:andrewb at inf.ethz.ch>> escribió:
> >>
> >>
> >>    Hi Zeus,____
> >>
> >>    __ __
> >>
> >>    We’re really bad with reclaiming memory, but I didn’t know it was
> >>    that bad! Honestly, there’s no good reason I can see for our heap
> >>    being that broken. From the quick glance through the code
> >>    (lib/c/src/malloc.c) my guess is that either the x86_64-specific
> >>    hack to avoid freeing memory allocated on another core is firing
> >>    incorrectly, or lesscore() is firing and doing something dumb. Could
> >>    you check which it is?____
> >>
> >>    __ __
> >>
> >>    I’m CCing Simon, who should know more about the workings of
> >>    lesscore().____
> >>
> >>    __ __
> >>
> >>    Andrew____
> >>
> >>    __ __
> >>
> >>    *From:* Zeus Gómez Marmolejo [mailto:zeus.gomez at bsc.es
> >>    <mailto:zeus.gomez at bsc.es>]
> >>    *Sent:* Wednesday, 21 September, 2011 6:14
> >>    *To:* barrelfish-users at lists.inf.**ethz.ch<barrelfish-users at lists.inf.ethz.ch>
> >>    <mailto:barrelfish-users@**lists.inf.ethz.ch<barrelfish-users at lists.inf.ethz.ch>
> >> >
> >>
> >>    *Subject:* [Barrelfish-users] Bug in malloc()/free() ?____
> >>
> >>    __ __
> >>
> >>    Hi,____
> >>
> >>    __ __
> >>
> >>    Here I introduce you a pretty simple program:____
> >>
> >>    __ __
> >>
> >>    int main(int argc, char **argv)____
> >>
> >>    {____
> >>
> >>    void *p;____
> >>
> >>    int i;____
> >>
> >>    ____
> >>
> >>    for(i=0; ;i++)____
> >>
> >>    {____
> >>
> >>    p = malloc(65536);____
> >>
> >>    if (p==NULL)____
> >>
> >>    USER_PANIC("malloc() returned NULL at %d", i);____
> >>
> >>    free (p);____
> >>
> >>    }____
> >>
> >>    ____
> >>
> >>    return 0;____
> >>
> >>    }____
> >>
> >>    __ __
> >>
> >>    This is ALWAYS aborting as:____
> >>
> >>    __ __
> >>
> >>    ERROR: myapp.0 in morecore_alloc()
> >>    ../barrelfish/lib/barrelfish/**morecore.c:85____
> >>
> >>    ERROR: vspace_mmu_aware_map fail____
> >>
> >>    Failure: ( libbarrelfish) Out of space in vspace_mmu_aware_map()
> >>    function [LIB_ERR_VSPACE_MMU_AWARE_NO_**SPACE]____
> >>
> >>    myapp.0 in main() ../barrelfish/usr/tests/myapp/**myapp.c:12____
> >>
> >>    malloc() returned NULL at 16382____
> >>
> >>    Aborted____
> >>
> >>    __ __
> >>
> >>    With the latest Barrelfish tree. Are you aware of this?____
> >>
> >>    __ __
> >>
> >>    __ __
> >>
> >>    --
> >>    Zeus Gómez Marmolejo
> >>    Barcelona Supercomputing Center
> >>    PhD student
> >>    http://www.bsc.es
> >>
> >>    ____
> >>
> >>
> >>
> >>
> >> --
> >> Zeus Gómez Marmolejo
> >> Barcelona Supercomputing Center
> >> PhD student
> >> http://www.bsc.es
> >>
> >>
> >>
> >
> 
> 
> --
> Zeus Gómez Marmolejo
> Barcelona Supercomputing Center
> PhD student
> http://www.bsc.es
> 