最近的一次分析问题的经历促使我写了这篇文章。
最近写了一个程序，基于开源界有名的libevent框架设计了一个服务器程序，运行在CentOS 6.3上，性能倒是不错，但是程序总在运行一段时间后消失，日志随机停在一个位置上，通过查看操作系统的日志/var/log/messages，发现了下面的内容：
Oct 31 14:02:33 CutSreen kernel: screenshot[11211]: segfault at 18 ip 000000362de6a44b sp 00007fb802fa5b20 error 4 in libstdc++.so.6.0.13[362de00000+e8000]
毫无疑问，自己的程序crash了，错误号是4，即表示非法的读访问。
马上想到通过core文件来定位错误，但是却没有发现我的core文件，后来就从AUPE书中找到下面几行内容，说明了为什么有时不会有core文件：
( a )进程是设置-用户-ID，而且当前用户并非程序文件的所有者； ( b )进程是设置-组-ID，而且当前用户并非该程序文件的组所有者； ( c )用户没有写当前工作目录的许可权； ( d )文件太大。core文件的许可权(假定该文件在此之前并不存在)通常是用户读/写，组读和其他读然后就一条条检查自己的环境，发现第3条不满足！/proc/[pid]/cwd显示的目录竟然是根目录(这么设置是由于我担心文件系统的去挂载影响程序运行)，我的程序运行用户对根目录没有写权限，于是就程序运行的当前目录设置为一个有写权限的目录，运行了一段时间后，core文件如期而至，问题点也找到了：程序中在多线程插入和删除STL的map时候忘记加锁了！
唉，大意了！但是，终究还是通过拿到core文件解决了问题。然后为了确保内存方面的可靠，又使用valgrind对代码进行了一次动态分析，结果报告显示内存无泄露。程序运行了很久，一直保持稳定。
希望自己的查错经历对大家分析问题有帮助！