I am wondering how the malloc() finally ends up calling the memory server but free() doesn't. Could it be this??<br><br><div class="gmail_quote">El 25 de septiembre de 2011 16:03, Simon Peter <span dir="ltr"><<a href="mailto:speter@inf.ethz.ch">speter@inf.ethz.ch</a>></span> escribió:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks for the patch. Now it takes a bit longer ... but it ends up by<br>
returning NULL anyway. The above program didn't change.<br>
<br>
> spawnd.0: spawning /x86_64/sbin/myapp on core 0<br>
myapp.0 in main() ../barrelfish/usr/tests/myapp/<u></u>myapp.c:12<br>
malloc() returned NULL at 30710<br>
Aborted<br>
</blockquote>
<br></div>
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.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
To add originality to the situation, sometimes I get this error too:<br>
ERROR: mem_serv.0 in mem_lmp_default_error_handler(<u></u>)<br>
./x86_64/lib/barrelfish/_for_<u></u>lib_barrelfish/mem_flounder_<u></u>bindings.c:1328<br>
ERROR: asynchronous error in Flounder-generated mem lmp binding (default<br>
handler)<br>
Failure: ( libbarrelfish) Failure in lmp_chan_alloc_recv_slot()<br>
[LIB_ERR_LMP_ALLOC_RECV_SLOT]<br>
Failure: ( libbarrelfish) Failure in slot_alloc() [LIB_ERR_SLOT_ALLOC]<br>
Failure: ( libbarrelfish) Failure in cnode_create() [LIB_ERR_CNODE_CREATE]<br>
Failure: ( libbarrelfish) Failure in ram_alloc() [LIB_ERR_RAM_ALLOC]<br>
Failure: ( libmm) No matching node found [MM_ERR_NOT_FOUND]<br>
Aborted<br>
</blockquote>
<br></div>
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.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
To give you some hints about the first error, it fails when calling to<br>
vspace_mmu_aware_map() in morecore.c:59 with error<br>
LIB_ERR_FRAME_CREATE_MS_<u></u>CONSTRAINTS. It turns out that (step <<br>
BASE_PAGE_SIZE). As this is the first call to that function in the loop,<br>
the buffer is NULL.<br>
As I see, in the latest version the debug_err() has been removed when<br>
reaching this condition.<br>
</blockquote>
<br></div>
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.<br>
<font color="#888888">
<br>
Simon<br>
</font></blockquote></div><br><br clear="all"><div><br></div>-- <br>Zeus Gómez Marmolejo<br>Barcelona Supercomputing Center<br>PhD student<br><a href="http://www.bsc.es" target="_blank">http://www.bsc.es</a><br><br><br>