liwen提供信息：
1、定位内存改写或者程序跑飞，指针异常等，可以采用electric-fence-2.1.13工具
该工具可以检测到读指针越界或者写指针越界操作。
sam提供经验：
程序跑飞问题原因汇总和对应措施:
1. 堆栈被破坏
问题原因: 一般都是局部变量越界操作，尤其是字符串缓冲区处理越界和数组处理越界等
问题规律：处理到特定的代码段才出问题，严重情况下，无法产生core-dump定位信息
应对措施：
(1) gcc编译参数，增加堆栈检查 -fstack-check 和 -fbounds-check 数组操作边界检查，经过实际检验，比较有效，能及时触发core-dump问题
(2) pc-lint代码静态检查，消除危险告警
（3）消息调度模块，记录最后处理的10条消息，只要系统不掉电，复位之后，立即获取上次死机前的10条消息，非常有用！
2. 非法操作
问题原因：一般都是非法指针操作或者被零除，比如读写非法地址等
问题规律：处理到特定的代码段才出问题，能产生有效的core-dump定位信息
应对措施：
（1）这类问题，其实最简单，触发core-dump，查看死机位置即可
3. 程序死锁
问题原因：临界资源使用冲突，导致程序挂死，触发硬件狗复位
问题规律：处理到特定的代码段才出问题，无core-dump信息，复位原因是硬件狗
应对措施：
（1）涉及到多线程的话，定位起来貌似有点复杂，不过凡是死锁问题，关掉硬件狗/软件狗后再DEBUG，一旦出问题，用gdb查看线程调用栈即可。
4. 内存涂改
问题原因：有一定的随机性，往往死在“不可能”的位置，程序中断言检查严格的话，也能发现蛛丝马迹
问题规律：处理特定的代码段之后，注意不是立即，然后死在另外一个地方，比如破坏内存堆的链表结构，往往死在下一次消息接收分配内存的时候
应对措施：
（1）曾经遇到的大部分问题，是内存堆的链表结构被破坏，一般只要跟踪一下系统处理的最后3条消息，准能找到这类问题的触发原因。
5. 资源耗尽
问题原因：系统运行一段时间，挂死复位
问题规律：时间是危险的敌人，可能死在任何一个地方
应对措施：
（1）定期检查一下系统资源使用情况，很容易界定该问题。假如是内存耗尽的话，做一次完整的内存分配和示范配对测试，就能定位这类问题
---------------------------------------------------------------------------------------------------------------------------------
常用工具：
1. gdb --- 编译时增加保护性检查代码，运行中查看调用栈/core-dump信息等
2. pc-lint --- 静态检查
3. core-dump --- linux系统产生的core-dump信息很完整，在DEBUG环境中完全启用
4. last 10 messages --- 启用后，在系统运行中实时记录，异常复位之后也能查看
5. opprofile --- 运行中监视内存非法操作等
---------------------------------------------------------------------------------------------------------------------------------
Tips:
1. 嵌入式设备，一定要保留一套强大的开发环境，比如内存足够大，带符号表运行程序，并且同时启动上述的一些诊断工具，
比如：用于特殊DEBUG的设备，FLASH和内存容量都翻倍，给软件提供一个良好的调试诊断环境，用于搞定这类复杂问题。
2. 前几年搞的一个大型项目（三年多），用上述几个绝招，搞定了系统绝大部分的疑难死机问题，供参考。