本文参考 http://stackoverflow.com/questions/2179403/how-do-you-read-a-segfault-kernel-log-message和http://www.slideshare.net/noobyahoo/introduction-to-segmentation-fault-handling-5563036
linux中 遇到 段错误的情况， 多数人会想到core dump， 但是不一定有，其实有其他的办法， 当进程出现这类问题的时候， 使用dmesg查看，会看到类似下面的信息(那stackoverflow中的例子来说)
kernel: myapp[15514]: segfault at 794ef0 ip 080513b sp 794ef0 error 6 in myapp[8048000+24000]
这样的报错， 或者有的时候 看见的是 xxx.so中出现错误， 如果看到glibc中的错误，不要怀疑是glibc的错误，因为我们的代码的错误可能在glibc中表现出来， 比如调用glibc中的函数，但是传的地址是非法地址就会出现这种情况。
方法很简单， 使用addr2line或者objdump， ip是对应的代码的地址， at是segfault的内存地址，多数情况不用，如果此处是0或者-1, 可以帮助查找原因，比如你的指针地址是NULL或者 (void *)-1, 多数情况根据ip足够了， error是错误原因， 暂不分析。
1 死在目标程序中
objdump -DCglS myappo >> /tmp/debug_message
然后vim /tmp/debug_message, 查找ip对应的地址080513b，
可能找到多个， 有的可能是debug等信息，没有仔细研究， 你可以很容易看到，在代码中的对应的文件和行数， 如果想看到代码，可能需要代码路径正确才行， ok， 这样你已经拿到了代码中出错的位置，基本简单的检查就可以找到错误的原因了。
2 死在xxx.so中， 报错中会有 xxx.so[AAA+BBB], AAA是加载地址， ip和AAA做减法得到的16进制数就是偏移了， 和上面做法一样， ok
3 死在glibc中， 这个可能比较麻烦，因为即使你找到了对应的函数，但是代码中调用的地方太多了，不容易定位，暂时还搞不定。
4 使用addr2line addr2line -f -e myapp 080513b
5 如果二进制文件是strip之后的， 此法失灵，可以把对应版本的代码重新编译，保留必要的信息，然后利用新生成的文件中查找地址。
6 对于内核代码也可以使用类似的方法，只要找到对应的ip的地址，拿到没有strip的二进制文件就ok。