printf输出死机

   今天老大给安排了个任务，查死机BUG

   这正是我喜欢的事情，于是二话不说投入200%的精力，开始查。话说此BUG 必先，一般来讲，毕现不是BUG，可是这个BUG却把我折腾的够呛，查了两个小时从有根据变成了没根据此BUG崩溃时我们dump出了他当时的寄存器值和堆栈的内容，提一下我们的运行环境arm1176,编译器为gcc 3.4.1。

   通过分析寄存器的值

   regs.ARM_pc = 0x401123bc    regs.ARM_lr = 0x4010a400
   regs.ARM_ip = 0x4012797c    regs.ARM_fp = 0xba7fcd68
   regs.ARM_cpsr = 0xa0000010


   access: [Read] address [0x000000e0]

   /proc/pid/maps里面我们需要的值

   400d8000-400d9000 rw-p 00005000 1f:03 117        /usr/local/lib/libintl.so.1.0.1
   400d9000-40120000 r-xp 00000000 1f:01 163        /lib/libuClibc-0.9.28.so
   40120000-40127000 ---p 40120000 00:00 0 
   40127000-40128000 r--p 00046000 1f:01 163        /lib/libuClibc-0.9.28.so
   40128000-40129000 rw-p 00047000 1f:01 163        /lib/libuClibc-0.9.28.so

   先看pc 0x401123bc - 0x400d9000 得0x393bc objdump libuClibc-0.9.28.so 

   死在了strnlen上

   393bc:e5d23000 ldrbr3, [r2]

   再看lr 0x4010a400 - 400d9000 得 0x31400

   反汇编为函数00030f18 <vfprintf>:

   31400:e598c010 ldrip, [r8, #16]

   

   综合以前的经验得出这就是printf %s 时给了一个非字符串变量，导致访问到了不该访问的地方（把int型变量看

   成了指向字符串的指针变量了），内核结束的程序。然后开始查代码，这段代码是界面点击驱动的，但是查了很

   长时间发现这条路走的很是艰难，退出来开始使用gdb挂着程序跑，死机后竟然什么信息都没有直接退出了

   open core dump

   死机后很长时间程序才退出，生成了一个将近200MB的文件，使用./gdb program core-file 然后backtrace得到

   死机的堆栈，感觉很奇妙，为什么连gdb挂着跑都不活不到死机时的信号，偏偏core file如此强大，不过问题确实

   被准确的定位了。

   问题解决。