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