[Barrelfish-users] Possible bug?

Zeus Gómez Marmolejo zeus.gomez at bsc.es
Thu Sep 15 01:17:39 CEST 2011


Ok, yes. You are right. There is an extra malloc() being done in the sender
when receiving back the buffer, done by the flounder stub that is not
free'd. I send you now the corrected version. But in any case, the user page
fault doesn't go away... :(

Thank you for your help

zeus.

El 15 de septiembre de 2011 00:55, Zeus Gómez Marmolejo
<zeus.gomez at bsc.es>escribió:

> Ok, I'm checking this now, but this is not the problem. In fact, it
> shouldn't fail anyway, as if malloc() fails, then the sender will fail when
> accessing the buffer, as the length is set to 65536 anyway.
>
> But the sender is never failing, is always the receiver who fails. (The
> buffer in the receiver side is being allocated in
> lib/barrelfish/flounder_support.c:424) It's the user's job to free the
> pointer allocated from the flounder stub. And this is always done in
> the continuation closure (function endr() ) in the receiver side.
>
> zeus.
>
> El 14 de septiembre de 2011 19:59, Baumann Andrew <andrewb at inf.ethz.ch>escribió:
>
>   Hi,****
>>
>> ** **
>>
>> A quick first thought: have you checked whether malloc() is failing and
>> returning NULL on the sender side, which is then being delivered as a
>> zero-length NULL buffer on the receiver? You do appear to have a memory leak
>> on the receiver (someone needs to free the buffer p after it has been sent),
>> so this might be the cause.****
>>
>> ** **
>>
>> Andrew****
>>
>> ** **
>>
>> *From:* Zeus Gómez Marmolejo [mailto:zeus.gomez at bsc.es]
>> *Sent:* Wednesday, 14 September, 2011 10:29
>> *To:* barrelfish-users at lists.inf.ethz.ch
>> *Subject:* [Barrelfish-users] Possible bug?****
>>
>> ** **
>>
>> Hi all,****
>>
>> ** **
>>
>> I'm trying the Barrelfish' ability of sending large buffers (now 64kb)
>> between cores using flounder. And I'm experiencing a strange behaviour.
>> After sending some messages, and running it for about 1 min in QEMU, the
>> program segfaults or simply hangs. I'm not sure if I am doing something
>> wrong... I'm trying it with the latest version of Barrelfish.
>> ****
>>
>> ** **
>>
>> The program is inspired in "usr/tests/idctest/idctest.c". It's spawning
>> another instance on core 1 and setting the binding. After that it creates
>> another thread to "dispatch events". The main loop in core 0 is sending
>> messages, while the main loop in core 1 is just waiting for a reply queue to
>> have some messages and send them back. It's using the same "test.if"
>> interface that idctest.c is using. I send it as an attachment. You can
>> simply try it by copying it over the existing idctest.c.****
>>
>> ** **
>>
>> So, core 0 is sending a message to core 1:****
>>
>> ** **
>>
>> *a = malloc(65536);*****
>>
>> *test_buf__tx(b, MKCONT(end, 0), a, 65536);*****
>>
>> ** **
>>
>> before sending it, it obtains a lock to ensure that next message is not
>> sent before the previous one has been  already sent:****
>>
>> ** **
>>
>> *  while (__sync_lock_test_and_set(&busy, true))*****
>>
>> *    thread_yield();*****
>>
>>   ****
>>
>> The continuation closure is releasing the lock:****
>>
>> ** **
>>
>> *static void end(void *r)*****
>>
>> *{*****
>>
>> *  free (a);*****
>>
>> *  busy = false;*****
>>
>> *}*****
>>
>> ** **
>>
>> This function is being called always by the second thread, which is always
>> dispatching messages. I know this is not very efficient to use this
>> spinlock... Is there any other way to block the thread and wake it up by the
>> other thread?****
>>
>> ** **
>>
>> Core 1 when receives the message:****
>>
>> ** **
>>
>> *static void buf1(struct test_binding *b, uint8_t *p, size_t buflen)*****
>>
>> *{*****
>>
>> *  debug_printf("buf1 %u\n", p[65535]);*****
>>
>> *  ambf_buff_send(p);*****
>>
>> *}*****
>>
>> ** **
>>
>> Simply prints the last position and sends it back to core 0: queuing it to
>> the other thread in order not to block the event dispatcher.****
>>
>> ** **
>>
>> The program segfaults when accessing to buffer p, in the previous
>> function, as sometimes p is null. In any case, there is no error reported...
>> ****
>>
>> ** **
>>
>> I would like to know if you see something wrong here ...****
>>
>> ** **
>>
>> ** **
>>
>> Many thanks!!****
>>
>> ** **
>>
>> --
>> 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/20110915/0149cc7e/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: idctest.c
Type: text/x-csrc
Size: 6010 bytes
Desc: not available
Url : https://lists.inf.ethz.ch/pipermail/barrelfish-users/attachments/20110915/0149cc7e/attachment-0001.bin 


More information about the Barrelfish-users mailing list