关于调试方法，100来拿分吧，英雄
小弟做arm通信设备开发，过程中遇到问题，还请各位指教：

    1.运行在ARM板子上有一个用于和其他设备进行通信的capwap协议守护进行，一直在后台运行并且不断与其他设备进行通信，当这个进程遇到段错误退出后，请问有没有什么高效的调试方法？？？（一直用printf加log信息定位，感觉定位问题的效率好低）

    2.gdb远程调试可行吗？ 另外，gdb可以调试这种不断发送接受数据的进程会有问题吗？？


还请各位大虾指教！！！
------解决方案--------------------
printf一直很高效的，gdb偶尔用下，不熟
------解决方案--------------------
1.运行在ARM板子上有一个用于和其他设备进行通信的capwap协议守护进行，一直在后台运行并且不断与其他设备进行通信，当这个进程遇到段错误退出后，请问有没有什么高效的调试方法？？？（一直用printf加log信息定位，感觉定位问题的效率好低）

    2.gdb远程调试可行吗？ 另外，gdb可以调试这种不断发送接受数据的进程会有问题吗？？


还请各位大虾指教！！！ 


第一问题，遇到段错误的时候，一般是内存越界造成的，找找有没有越界的。
printf不要在数据通信的时候加，数据通信数据量大，效率特别低，可以出错地方加。或是一段时间后用。
还有就是找一些段错误的规率，一定时间内还是执行什么操作，减少范围查找
第二个问题，gdb调试数据量大的数据时，一般不用，因为你调试的时候数据已经不对了。
------解决方案--------------------
远程调试需要目标机和调试机器上都装了gdb.

如果可以直接本地调式,直接gdb attach上进程,进程crash的时候自动会被gdb捕获,你可以用bt查看下出错的地方

进程编绎时最好加上-g,不然gdb调试看不到符号信息
------解决方案--------------------
同一2楼的添加printf的方法；
gdb用的不多，多线程的时候，gdb更不好用，尤其有心跳时间的限制；
------解决方案--------------------
能产生coredump文件的话，直接加载到gdb可以看看堆栈信息。
------解决方案--------------------

引用

A: gdb真难用,更本就是给六个手指的外星生物用的.真不知道linux那帮怪咖使用的是什么思维.
B: 有coredump还不爽?gdb-server简直是天堂!     看我们苦逼的看着中断n个进程线程打印出来的牛屎都快吐了
C: 有终端看还不知足?           看我们苦逼的睁着狗眼看着逻辑分析仪跳的毛线一样的线条.
D: 有分析仪还不知足?           看我们整天听这客户电话里说,A灯亮了,B灯在闪烁,C灯暗--亮--暗-亮--,跟他妈二战间谍似的.
E: 知足吧,你根本没法想象,我启动程序等了几万年,就出来一个42.天知道

好吧其实gdb真的很好了,只要多学习怎么使用.别砸到自己.
------解决方案--------------------
1. 在arm上生成core文件, 再用gdb看调用栈即可

2. 搜索gdbserver