 |
 |
Thanks for reporting it! An analysis (so we don't need to go through the back traces over and over again): **Thread1:** Calls the object finallizer: XrdCl::DefaultEnv::Finalize, which in turn calls XrdCl::PostMaster::Stop -> XrdCl:: PollerBuiltIn:: Stop, at that point the **XrdCl::PollerBuiltIn::pMutex** gets locked, then we continue up the stack until XrdSys::IOEvents::Poller::SendCmd, where a semaphore is being created and sent through a pipe as part of PipeData struct, and than the **XrdSysSemaphore::Wiat()** routine is being called, at that point Thread1 gets stuck. **Thread3:** The XrdSys::IOEvents::PollE::Begin calls the XrdSys::IOEvents::Poller::TmoGet routine that is suppose to provide the timeout value for epoll_wait. If we go up the stack we will reach XrdCl::PollerBuiltIn::RemoveSocket, where Thread3 tries to lock **XrdCl::PollerBuiltIn::pMutex**, at that point Thread3 gets stuck (the mutex was previously locked by Thread1). Few lines under the XrdSys::IOEvents::Poller::TmoGet, Thread3 calls XrdSys::IOEvents::PollE::Process, which retrieves the PipeData struct, and posts the semaphore Thread1 is waiting for. However Thread3 never gets there, because it is waiting for a mutex that has been locked by Thread1. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/issues/418#issuecomment-248855290 ######################################################################## 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