HOS调试技术.ppt

HOS调试技术 北京昊海科技 印朝晖 内容 OS基本的概念 辅助调试机制 例子 HOS与Vxworks的关系 任务 任务状态 通过shell来观察任务状态 i命令 HOS的内存机制 KMalloc 采用页＋块的方式实现 适合固定大小块的分配 速度快，垃圾回收简单 在A版可以记录内存的分配情况 大于8192（最大块的大小）的分配，间接调用Malloc 部分发现写越界情况 观察内存使用状况（Kmalloc） Show slab global 观察内存使用状况（malloc） 利用vxworks的browser来看 内存泄漏 Show slab module [module no] [diff] Timer HOS中Timer是由一个tTimer任务来触发的 与Vxworks无关 不要把timerout callback函数搞的做太多事情 查看目前活跃的Timer Show slab timer WDB调试机制 Shell 要调试，先把shell开着 Shell的一些常用命令 i tt semShow 直接在shell上执行某个函数 直接在shell上改变全局变量数值 在shell上查看调用栈 tt 任务名字或者任务id 在shell上查看信号量 semShow Browser 查看malloc内存 查看每个任务的堆栈使用情况 查看有没有堆栈溢出 调试器 慎用调试器，调试器不是万能钥匙 大部分问题的解决都不需要使用调试器来跟踪 能不attach系统，就不挂，直接attach某个任务 要attach系统，必须先关了软件狗 注意点 不要加太多breakpoint，最好能随时删除 不要打开太多文件窗口，随手关闭 需要时再加watch变量，看完删除 Backtrace有时候不能正常工作，双击它，有时候又可以了 系统启动时的调试 等系统起来，出问题的地方已经过了 PPC仿真工具 记得设置CPU类型 出现Assert时，使用 r.s ip 0x地址来查看调用栈 出现全局变量被其他模块写了，有是在没招，可以通过看看符号表，一般而言，临近的数据结构比较有怀疑 问题的定位 依赖背景知识 依赖对于出错症状的判断 读代码 调试 常用的调试方法 二分法 插入式调试 不变式 内存被写的错误 解决的充分条件：在能容忍的时间内把把复现 思路：找到被写的数据，构造辅助检查函数，在触发条件流程中插入检查函数，逐步缩小范围 例子1：现象 用Script在G系列上不停的创建Tunnel接口，最后出现分配内存失败的错误。Kmalloc提示没有内存了。 还好问题可以复现 例子1：现象分析 例子1：可能性排除 在script中每增加一个tunnel接口，show一次内存 结果：在最后一次创建Tunnel口之前，内存还有上千页 说明不是内存用完导致的，就要找写坏内存数据结构的黑手 例子1：查找疑犯 Show run看当前配置，还好配置不多。配置里面有IPSec和OSPF。 先尝试排除OSPF，结果，去掉OSPF配置，问题不出现了，一把命中。配置上OSPF，去掉IPSec，问题出现。 说明问题：肯定与IPSec无关，OSPF不是凶手就是目击证人 怎么快速的缩小怀疑范围 有的时候，配置有一大堆。复现的操作有好多步。 先尝试排除自己熟悉的模块 先尝试怀疑历史记录不良的模块 先尝试排除自己认为最不可能的操作 要严谨，不要想当然。 例子1：千里追踪 目前有个假设：kmalloc的数据结构被OSPF搞坏了 错误显示的是空闲页面队列为0 确定检查函数 在OSPF的每个主要处理过程的开始结束调用此函数 例子1：找到窝藏地 发现在OSPF报文发送过程导致 二分缩小范围 最后到了报文构造函数 例子1：最后的花絮 OSPF的报文构造函数看不出异常来，不像有写越界的情况，里面有一个分配内存的地方，就是出错的地方 “仔细”观察，还是没招 幸好问题总在创建第几个Tunnel时出现，加条件断点，在出问题这一次单步跟踪 发现存在一个可能的路径会导致死循环分配内存 原来如此 例子1：回顾 失败处 过程中存在错误假定，后果就是导致看代码时没往内存用完方向考虑，光看内存操作的地方了 成功处： 合理的锁定了疑犯 过程中出现错误假设，但是要设置的检查不变式是根据实际报告的错误写的，反映实际情况 借鉴 出现问题了，一定要仔细分析现象，争取搞出把把复现的最小条件集合来，先缩小范围在推理 把自己的假设写出来，不要时间长了把自己的假设当作事实了 有多个可能的情况，用笔一个个列出来，一一试验 遇到迷惑处，在推敲下自己的假设和思考过程 任务创建 定时器 内存分配 vxwroksAPI（信号量、消息队列） 注意，用VOS创建的任务，用VOS的退出、删除函数清除任务。 READY?The stat