[Barrelfish-users] Possible bug?

[Zeus Gómez Marmolejo]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.inf.ethz.ch/pipermail/barrelfish-users/attachments/20110915/af0ddd3a/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: idctest.c
Type: text/x-csrc
Size: 5999 bytes
Desc: not available
Url : https://lists.inf.ethz.ch/pipermail/barrelfish-users/attachments/20110915/af0ddd3a/attachment.bin