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

Thu Sep 22 19:33:49 CEST 2011

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.
>>
>> The program is always stopping after allocating about 1Gb of memory,
>> which is the size of the physical memory of the virtual machine....
>>
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.inf.ethz.ch/pipermail/barrelfish-users/attachments/20110922/c70d9b0c/attachment-0001.html 