一小伙说他的程序死锁了，让帮忙看看。对死锁问题，首先祭出GDB这一神器。
|
(gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xf7fa790e in __lll_mutex_lock_wait () from /lib/libpthread.so.0 #2 0xf7fa3a8b in _L_mutex_lock_81 () from /lib/libpthread.so.0 #3 0xf7fa35be in pthread_mutex_lock () from /lib/libpthread.so.0 #4 0x08316692 in mooon::sys::CLock::lock (this=0x89f59e0) |
第一步的目标是找到锁被谁持有了，这只需要找到死锁的位置，然后查看pthread_mutex_t.__owner值是什么。接下来使用GDB的“info threads”命令找到持有的线程。
找到持有的线程后，查看它的调用栈：
|
#0 0xffffe410 in __kernel_vsyscall () #1 0xf7daea16 in __gxx_personality_v0 () from /lib/libc.so.6 #2 0xf7ddccbc in usleep () from /lib/libc.so.6 #3 0x0825a374 in CSHMPkg::LockWait (this=0xddb3ebb0) at SHMPkg.cpp:221 |
这个时候需要看对应的源代码：
|
bool CSHMPkg::LockWait() { if (strlen(m_lockFilePath) <= 0) return false; while (!m_readLock.LockFile(m_lockFilePath)) usleep(10); return true; } |
进一步看加文件锁的代码：
|
bool CFileLock::LockFile(const char* filePath) { m_fd = open(filePath, O_WRONLY|O_TRUNC, S_IRUSR|S_IWUSR); if(m_fd == -1) return false; if (write_lock(m_fd, 0, SEEK_SET, 1) == -1) { close(m_fd); m_fd = -1; return false; } return true; } |
初步估计while处死循环了，在usleep处打个断点可轻松确定是否死循环。结果确认这里是死循环了。因此问题在LockFile函数，它应当是返回了false。通过单步调试，发现是open失败。检查文件filePath存在，且权限正常，需要找出open失败的原因。
因为open是个系统调用，因此只需要知道errno值即可知道原因。但errno是个宏，不能直接打印，找到宏errno的定义：
|
# define errno (*__errno_location ()) |
在GDB中调用__errno_location()，发现errno的值为24：
|
#define EMFILE 24 /* Too many open files */ |
到这里，问题已清楚，执行shell命令ulimit -a查看，发现“open files”值为1024，在当下的服务器，1024是一个比较小的值。程序中大量采用redis集群直连，对fd的需求很大，进一步执行“netstat -antp”或lsof也可以看到。
因此解决办法是调大“open files”值，临时可使用ulimit调大，但一般还是得修改文件limits.conf。有关limits.conf，可阅读另一博文《源码解读Linux的limits.conf文件》。