一个死锁分析过程

喜欢ヅ旅行 2024-04-18 15:03 57阅读 0赞

一小伙说他的程序死锁了，让帮忙看看。对死锁问题，首先祭出GDB这一神器。

<table style="width:426.1pt;"> 
 <tbody> 
  <tr> 
   <td style="vertical-align:top;width:426.1pt;"> <p style="margin-left:0pt;">(gdb) bt</p> <p style="margin-left:0pt;">#0 &nbsp;0xffffe410 in __kernel_vsyscall ()</p> <p style="margin-left:0pt;">#1 &nbsp;0xf7fa790e in __lll_mutex_lock_wait () from /lib/libpthread.so.0</p> <p style="margin-left:0pt;">#2 &nbsp;0xf7fa3a8b in _L_mutex_lock_81 () from /lib/libpthread.so.0</p> <p style="margin-left:0pt;">#3 &nbsp;0xf7fa35be in <strong><strong>pthread_mutex_lock</strong></strong>&nbsp;() from /lib/libpthread.so.0</p> <p style="margin-left:0pt;">#4 &nbsp;0x08316692 in mooon::sys::CLock::lock (this=0x89f59e0)</p> </td> 
  </tr> 
 </tbody> 
</table>

第一步的目标是找到锁被谁持有了，这只需要找到死锁的位置，然后查看**pthread\_mutex\_t.****\_\_owner**值是什么。接下来使用GDB的“info threads”命令找到持有的线程。

找到持有的线程后，查看它的调用栈：

<table style="width:426.1pt;"> 
 <tbody> 
  <tr> 
   <td style="vertical-align:top;width:426.1pt;"> <p style="margin-left:0pt;">#0 &nbsp;0xffffe410 in __kernel_vsyscall ()</p> <p style="margin-left:0pt;">#1 &nbsp;0xf7daea16 in __gxx_personality_v0 () from /lib/libc.so.6</p> <p style="margin-left:0pt;">#2 &nbsp;0xf7ddccbc in usleep () from /lib/libc.so.6</p> <p style="margin-left:0pt;">#3 &nbsp;0x0825a374 in CSHMPkg::<strong><strong>LockWait </strong></strong>(this=0xddb3ebb0) at SHMPkg.cpp:221</p> </td> 
  </tr> 
 </tbody> 
</table>

这个时候需要看对应的源代码：

<table style="width:426.1pt;"> 
 <tbody> 
  <tr> 
   <td style="vertical-align:top;width:426.1pt;"> <p style="margin-left:0pt;">bool CSHMPkg::LockWait()</p> <p style="margin-left:0pt;">{ </p> <p style="margin-left:0pt;">&nbsp;&nbsp;if (strlen(m_lockFilePath) &lt;= 0) return false;</p> <p style="margin-left:0pt;"><strong><strong>&nbsp;&nbsp;while </strong></strong>(!m_readLock.<strong><strong>LockFile</strong></strong>(m_lockFilePath))</p> <p style="margin-left:0pt;">&nbsp;&nbsp;&nbsp;&nbsp;usleep(10);</p> <p style="margin-left:0pt;">&nbsp;&nbsp;return true;</p> <p style="margin-left:0pt;">}</p> </td> 
  </tr> 
 </tbody> 
</table>

进一步看加文件锁的代码：

<table style="width:426.1pt;"> 
 <tbody> 
  <tr> 
   <td style="vertical-align:top;width:426.1pt;"> <p style="margin-left:0pt;">bool CFileLock::<strong><strong>LockFile</strong></strong>(const char* filePath)</p> <p style="margin-left:0pt;">{ </p> <p style="margin-left:0pt;">&nbsp;&nbsp;m_fd = <strong><strong>open</strong></strong>(filePath, O_WRONLY|O_TRUNC, S_IRUSR|S_IWUSR);</p> <p style="margin-left:0pt;">&nbsp;&nbsp;if(m_fd == -1)</p> <p style="margin-left:0pt;">&nbsp;&nbsp;&nbsp;&nbsp;return false;</p> <p style="margin-left:0pt;">&nbsp;&nbsp;if (write_lock(m_fd, 0, SEEK_SET, 1) == -1) { </p> <p style="margin-left:0pt;">&nbsp;&nbsp;&nbsp;&nbsp;close(m_fd);</p> <p style="margin-left:0pt;">&nbsp;&nbsp;&nbsp;&nbsp;m_fd = -1;</p> <p style="margin-left:0pt;">&nbsp;&nbsp;&nbsp;&nbsp;return false;</p> <p style="margin-left:0pt;">&nbsp;&nbsp;}</p> <p style="margin-left:0pt;">&nbsp;&nbsp;return true;</p> <p style="margin-left:0pt;">}</p> </td> 
  </tr> 
 </tbody> 
</table>

初步估计**while**处死循环了，在**usleep**处打个断点可轻松确定是否死循环。结果确认这里是死循环了。因此问题在LockFile函数，它应当是返回了false。通过单步调试，发现是open失败。检查文件filePath存在，且权限正常，需要找出open失败的原因。

因为open是个系统调用，因此只需要知道errno值即可知道原因。但errno是个宏，不能直接打印，找到宏errno的定义：

<table style="width:426.1pt;"> 
 <tbody> 
  <tr> 
   <td style="vertical-align:top;width:426.1pt;"> <p style="margin-left:0pt;"># &nbsp;&nbsp;define <strong><strong>errno </strong></strong>(*<strong><span style="color:#210dfc;"><strong>__errno_location</strong></span></strong>&nbsp;())</p> </td> 
  </tr> 
 </tbody> 
</table>

在GDB中调用\_\_errno\_location()，发现errno的值为**24**：

<table style="width:426.1pt;"> 
 <tbody> 
  <tr> 
   <td style="vertical-align:top;width:426.1pt;"> <p style="margin-left:0pt;">#define EMFILE <strong><span style="color:#210dfc;"><strong>24</strong></span></strong> /* <strong><span style="color:#ff0000;"><strong>Too many open files</strong></span></strong>&nbsp;*/</p> </td> 
  </tr> 
 </tbody> 
</table>

到这里，问题已清楚，执行shell命令ulimit -a查看，发现“open files”值为1024，在当下的服务器，1024是一个比较小的值。程序中大量采用redis集群直连，对fd的需求很大，进一步执行“netstat -antp”或lsof也可以看到。

因此解决办法是调大“open files”值，临时可使用ulimit调大，但一般还是得修改文件limits.conf。有关limits.conf，可阅读另一博文《[源码解读Linux的limits.conf文件][Linux_limits.conf]》。

[Linux_limits.conf]: https://blog.csdn.net/Aquester/article/details/86694644