Was this behavior on a recent (last few days) version of git master HEAD? There was a patch merged today <a href="http://review.gluster.com/3783">review.gluster.com/3783</a> which might have an influence related to what you are seeing.<div>
<br></div><div>Avati</div><div><br><div class="gmail_quote">On Tue, Aug 7, 2012 at 2:05 AM, Emmanuel Dreyfus <span dir="ltr"><<a href="mailto:manu@netbsd.org" target="_blank">manu@netbsd.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi<br>
<br>
I am tracking portability problems in syncio.c. It maks heavy usage<br>
of swapcontext(), which is something not recommanded (it was removed<br>
from the 2008 edition of POSIX.1).<br>
<br>
As I understand, syntask_wrap() has the problem of retreiving the task.<br>
The parameter padded by makecontext() is not reliable, since the<br>
standard does not specify the type of the argument. Passing a pointer<br>
on an LP64 machine is doomed to fail if the par ameter is taken as<br>
an int by the implementation.<br>
<br>
Therefore the author of the code used thread specific storage to pass<br>
the task ,through synctask_set() / syntask_get(). I encounter<br>
crashes because syntask_get() in syntask_wrap() gets NULL, or even<br>
get a value different than the one synctask_set() gets as its argument.<br>
Using synctask_set() argument tend to be much more reliable at mine<br>
than trusting syntask_get().<br>
<br>
Logging pthread_self() and task in synctask_new(), syntask_switchto()<br>
and synctask_wrap, I can see the reason why it fails:<br>
syntask_switchto() / syntask_set() is sometimes done in a different<br>
thread that the one where synctask_wrap resumes. I suspect we fall<br>
into unspecified behavior with thread and swapcontext() interractions.<br>
Given that swapcontext() is not standard anymore, this would not be<br>
very suprising.<br>
<br>
I try to think about a workaround of the problem. An idea would<br>
be to store something specific to the context, like stack address,<br>
in struct synctask. syntask_wrap() could retreive the task by<br>
looking up its own stack address with getcontext() and search a<br>
matching task in a global list of tasks. I am not sure this is<br>
leading anywhere, though.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Emmanuel Dreyfus<br>
<a href="mailto:manu@netbsd.org">manu@netbsd.org</a><br>
<br>
_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@nongnu.org">Gluster-devel@nongnu.org</a><br>
<a href="https://lists.nongnu.org/mailman/listinfo/gluster-devel" target="_blank">https://lists.nongnu.org/mailman/listinfo/gluster-devel</a><br>
</font></span></blockquote></div><br></div>