I can consistently provoke a deadlock in the file cache (version 4.2.0):
```
#0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136
#1 0x0000003120209508 in _L_lock_854 () from /lib64/libpthread.so.0
#2 0x00000031202093d7 in __pthread_mutex_lock (mutex=0x7f86ec0057c8) at pthread_mutex_lock.c:61
#3 0x00007f86fbddd110 in Lock (this=0x7f86ec0056b0, __in_chrg=<value optimized out>) at /usr/src/debug/xrootd/xrootd/src/XrdSys/XrdSysPthread.hh:57
#4 XrdFileCache::Prefetch::~Prefetch (this=0x7f86ec0056b0, __in_chrg=<value optimized out>) at /usr/src/debug/xrootd/xrootd/src/XrdFileCache/XrdFileCachePrefetch.cc:133
#5 0x00007f86fbdde57f in XrdFileCache::IOEntireFile::Detach (this=<value optimized out>) at /usr/src/debug/xrootd/xrootd/src/XrdFileCache/XrdFileCacheIOEntireFile.cc:77
#6 0x000000312260a4cc in XrdPosixFile::~XrdPosixFile (this=0x7f86ec0031e0, __in_chrg=<value optimized out>) at /usr/src/debug/xrootd/xrootd/src/XrdPosix/XrdPosixFile.cc:84
#7 0x000000312260a6a9 in XrdPosixFile::~XrdPosixFile (this=0x7f86ec0031e0, __in_chrg=<value optimized out>) at /usr/src/debug/xrootd/xrootd/src/XrdPosix/XrdPosixFile.cc:93
#8 0x000000312260dc4f in XrdPosixXrootd::Close (fildes=<value optimized out>) at /usr/src/debug/xrootd/xrootd/src/XrdPosix/XrdPosixXrootd.cc:166
#9 0x00007f86fc200c41 in XrdPssFile::Close (this=0x7f86ec0031b0, retsz=<value optimized out>) at /usr/src/debug/xrootd/xrootd/src/XrdPss/XrdPss.cc:734
#10 0x000000312126a86a in XrdOfsHandle::Retire (this=0x245df48, retc=@0x7f86fc960d98, retsz=0x0, buff=<value optimized out>, blen=0)
at /usr/src/debug/xrootd/xrootd/src/XrdOfs/XrdOfsHandle.cc:400
#11 0x0000003121260107 in XrdOfsFile::close (this=0x7f86ec003810) at /usr/src/debug/xrootd/xrootd/src/XrdOfs/XrdOfs.cc:753
#12 0x0000003121259151 in XrdXrootdProtocol::do_Close (this=0x7f86ec002df0) at /usr/src/debug/xrootd/xrootd/src/XrdXrootd/XrdXrootdXeq.cc:474
#13 0x000000312165e119 in XrdLink::DoIt (this=0x7f86ec002b38) at /usr/src/debug/xrootd/xrootd/src/Xrd/XrdLink.cc:397
#14 0x00000031216615f5 in XrdScheduler::Run (this=0x610038) at /usr/src/debug/xrootd/xrootd/src/Xrd/XrdScheduler.cc:333
#15 0x00000031216617e9 in XrdStartWorking (carg=<value optimized out>) at /usr/src/debug/xrootd/xrootd/src/Xrd/XrdScheduler.cc:85
#16 0x00000031216263af in XrdSysThread_Xeq (myargs=0x244b250) at /usr/src/debug/xrootd/xrootd/src/XrdSys/XrdSysPthread.cc:86
#17 0x00000031202079d1 in start_thread (arg=0x7f86fc961700) at pthread_create.c:301
#18 0x000000311fee88fd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
```
where the thread is stuck trying to acquire a lock it already holds.
I think the cause is Prefetch::InitiateClose in XrdFileCache/XrdFileCachePrefetch.cc (called previously from XrdOfsFile::close() via IOEntireFile::ioActive()
```C++
bool Prefetch::InitiateClose()
{
// Retruns true if delay is needed
clLog()->Debug(XrdCl::AppMsg, "Prefetch::Initiate close start", lPath());
if (m_cfi.IsComplete()) return false;
m_stateCond.Lock();
if (m_started == false) return false;
m_stopping = true;
m_stateCond.UnLock();
return true;
}
```
if `m_started` is false `m_stateCond` is not unlocked, causing a self-deadlock when the destructor tries to lock it again.
---
Reply to this email directly or view it on GitHub:
https://github.com/xrootd/xrootd/issues/239
########################################################################
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
