金九 的技术博客

最近用python的requests写个爬虫下载

1、查看内核文件中函数的执行流程        前段时间研究了一下Linux内核信号处理流程，记录一下用到的技巧吧。        其实如果不用工具，硬是看代码去分析这个信号处理流程的话，还真的可能搞不定，因为不知道看到的代码是否得到执行，有可能都没有编译进去，所以适当的用工具去分析和调试，真的事半功倍。那信号处理从哪里入手呢，当然从系统调用开始，这就用到SystemTap使用技巧【一】中

很多程序长期在线上系统跑着，可能跑着跑着就coredump了，而这种bug比较难复现，这个问题估计困扰不少同行朋友，这里记录一下我的一些思路，如有不对之处，欢迎指正。1、coredump文件       这个方法很基础了，相信大家都知道，具体步骤如下：ulimit -c unlimitedulimit -c unlimited' >> /etc/profileservice a

最近碰到这么一个问题：程序先获得锁，然后进行一些操作，操作完成之后再把锁释放掉，然而在获得锁之后进行的一些操作中可能导致程序异常退出（比如段错误），可以看出还没有来得及把锁释放进程就蹦掉了，从而导致这个锁长期没有被释放，其他想尝试获取锁的进程都会失败。       这个问题在多进程模型中很容易出现，下面是一个比较简单的多进程模型程序例子：dead_lock.c：#include #i

1、代码执行路径     在分析代码的时候，能清晰地观察代码执行路径对Debug效率很有帮助，比如，最近在分析内核tcp回复ack的代码执行路径的时候就用到这个技巧2、调试内核模块参考：http://blog.chinaunix.net/uid-14528823-id-4726046.html

python虽然是脚本语言，但有时候也会出一些奇怪的问题，比如假死之类 的。对脚本语言来说，调试比较简单，加个print语句就可以了，这也是比较原始的方法，简单的问题print基本上可以解决，但复杂的问题，还是得通过调试器来辅助啊。最近就碰到比较棘手的问题，一个python爬虫进程运行一周之后就假死了，不知道是什么原因导致的，这个爬虫进程要是C写的二进制程序就好办了，直接gdb attach上

SystemTap是一个强大的调试工具，确切的说应该是一门调试语言，因为它有自己的语法，也有解析、编译、运行等过程（准确的说有五个阶段），但它主要解决的问题是收集Linux内核或者用户进程的信息，主要目的是调试。我一直以为gdb、kgdb是Linux最强大的调试器，曾经爱不释手，自从发现了SystemTap之后，又有了当初喜欢gdb的那种感觉了，真的是相见恨晚啊。gdb和SystemTap不是竞争

在debug二进制程序的时候，难免会用到

systemtap入门文章参考：http://blog.youkuaiyun.com/justlinux2010/article/details/17653601

问题：        我在nginx中fork出一个进程来专门做DNS解析的工作，在本地开发环境中一切正常，而在线上服务器环境中这个进程就不定期的死掉重启，而且还不太容易复现。排查：        直接在线上服务器开启coredump，让linux帮忙把进程挂掉时的core文件保存下来，再用gdb分析，后来如愿得到core文件了，用gdb调试，从调用堆栈来看，是死在glibc的_int