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, view it on GitHub, or mute the thread.

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