android native层printf的一个bug

由于我们的程序是native C层程序，在机顶盒上跑的时候，没有任何的反馈界面，调试只能通过printf或者cout打印，而我们程序本身也慢慢的由两个线程编程3个4个甚至更多；

  两个线程的时候，程序跑个半天左右就会出现卡死现象，4个线程的时候，卡死出现的时间更短了，半个小时，十来分钟就一定会卡死，而我们追踪卡死现象的方法就是添加更多的log，每次卡死的时候，打印的log都非常奇怪，经过查找，这个卡死的地方都不会有问题。

   当我们程序只有两个线程时，我们关掉一个模块的log模块，就不会有卡死问题，当时大家开始怀疑printf是不是有问题，之后做了单独测试多线程时printf的测试，都没有卡死，反而是printf和cout混用时会死掉，所以我们去掉所有cout，只留pritnf，多个线程log全开，跑起来还是会死。

   当这个问题纠结了3个月的时候，我开始怀疑是我们的调试方法太落后，根本不知道怎么去找问题，所以，开始研究gdbserver，经高手指点，得到gdb的大致方法，加之自己的摸索，前后几天，搞定

 方法大致如下：

1 修改Application.mk 里优化等级为APP_OPTIM=debug

        2 用ndk-build编译

        3 将obj/local/armeabi-v7a下的所有程序拷贝到开发板上，并拷贝一份至本机例如/dir1

        4 通过串口或者adb连接到开发板

    在开发板上 gdbserver linux机器ip:端口号 程序名

        5 在linux机器上进入到程序所在目录：

 /...../android-ndk-r8b/toolchains/arm-linux-androideabi-4.6/prebuild/linux-x86/bin/arm-linux-androideabi-gdb 程序名

此后这一步非常重要，因为之前没有走一步，或者没有设置好这一步，导致了出错时不能打印出栈信息

      (gdb)set solib-search-path /home/mydir/...../...sublib  这个目录下的所有so库全都必须跟机顶盒上的一致，才能保证出错时，系统能找出出错的位置，我的方法是，把所有需要的so库从机顶盒上拷贝出来放到这里

      (gdb) target remote 机顶盒Ip：端口号

      (gdb)c

    这个时候，等待卡死的发生吧

    等出现Program received signal SIGSEGV,Segmentation fault时，敲bt，就可以看见卡死的的栈信息了

  出乎我意料的是，每次卡死都在printf上，好吧，只能给它加锁了，加锁后，问题搞定，没有再死过