Hi Dirk, Sad to say it took me 7 months, but I think I have the issue fixed! In the end, it wasn't a mysterious threading or memory management issue - a simple logic mistake exists in the new client when reading ReadV requests. Any user of the new client sufficiently unlucky should be able to trigger it - all that needs to be done is perform ReadV (no threading necessary!). In our tests (which "encourage" the race condition because things are read over the wide area), about 10% of jobs die due to it. IMHO, this definitely needs to be backported to the stable series. Brian On Apr 24, 2014, at 2:54 AM, xrootd-dev <[log in to unmask]> wrote: > Hi Brian, > > Lukasz is probably still traveling - let me know if we need someone to look at this before he is back on May 5th. > > > Cheers, Dirk > > On 24 Apr 2014, at 05:42, Brian Bockelman <[log in to unmask]> wrote: > > > Hi @ljanyst - > > > > Any further thoughts on this one? I'm still stumped and large-scale testing hasn't really revealed any more clues. > > > > Currently, this is the last thing standing in the way from using the new client in CMS. > > > > Brian > > > > — > > Reply to this email directly or view it on GitHub. > > > > > > Use REPLY-ALL to reply to list > > > > To unsubscribe from the XROOTD-DEV list, click the following link: > > https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1 > > > — > Reply to this email directly or view it on GitHub. > --- Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/issues/45#issuecomment-41290997 ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1