编译器内存问题调试技术讲座.pptVIP

软件调试经验交流 zhongguoguojijiankongyanjiuyuzhouzhongxin 编译器选项 目前监控系统采用中的编译器 vc6、intel-c++9.0 solaris-CC CXX6.1…… 以solaris和windows为代表 编译选项的不同会给调试带来不同的结果，需要细致选择 dbx 常用命令 debug/attach debug progname pid attach pid detach/kill up/down /frame frame –h print whereis whatis threads /thread Solaris调试符号 -g 生成调试符号，相关动态库也必须如此生成才能看到源代码 release模式下仅提供栈回溯信息察看 debug模式可以定位到代码行，查看函数参数 可使用strip命令剥离调试符号 Windows编译器选项 /GZ 运行时安全检查 与/Ox冲突 /RTC vs7以上有效，运行时安全检查 /Zi 生成完整的调试信息 与/Ox冲突 /GS 缓冲区安全检查 /Od 禁用优化信息 windbg常用命令 k　显示栈 ~ 显示线程 ~* ~. ~# *全部 .当前 #故障 d/da/db/dd x 查找符号 r 寄存器 .cls g .reload .lastevent gflags—设置系统调试选项 System Registry 对系统设置，所用进程生效 Kernel Flags 对设置后所有新运行进程生效，重起后失效 Image Files 对单个模块生效 gflags Windows系统调试符号的获取 设置环境变量 Set _NT_SYMBOL_PATH = symsrv*c:\localsymbols*/download/symbols 调试包中的SymChk.exe 实用工具 调试符号文件(PDB) 具备时标信息，严格匹配 对于操作系统符号推荐使用SRV语法，动态获取，如需出差可下载离线安装包 /whdc/DevTools/Debugging/symbolpkg.mspx 常见内存问题的分类 设置系统调试标志 PageHeap Application Verifier gflags 内存堆调试的常用调试标志 solaris 使用运行期检查 dbx 使用check –access 相对来说，unix的内存保护机制比windows要好的多，基本上可以在第一现场崩溃 Windows stack unwinding 问题 windows的栈展开依赖于调试符定位，与编译时优化的栈指针省略也有关系。 重新编译程序，匹配调试符号 关闭程序优化 手工构造程序栈参见/en-us/library/cc267826.aspx 栈问题困难所在 操作系统默认不对程序栈进行检查 如果开启FPO，会导致程序真正崩溃时的栈信息错误，无法获取有效信息 栈破坏问题的调试经验 并无特别好的调试方法 常见原因是栈上创建的数组或者字符串越界，开启缓冲区检查，有助于帮助调试该问题 大致定位后仔细跟踪 相对而言，unix系统的情况好一些，一般可以及时发现栈破坏而主动dump 内存泄漏调试的基本方法 无论什么方法，大都是映射到最底层的内存分配/释放调用进行配对，同时记录分配时的调用栈，确定泄漏地址。 工具和方法都不是万能的，并且生成报告相当繁琐，需要仔细查找和耐心分析。 对于引用计数类误报率很高（QString） 内存泄漏 资源泄漏--windows 调试器调试 使用专门的微软检测工具 静态代码检查工具 –漏报率较高 Purify运行时检查 –误报率很高 设置正确的调试标志很重要 内存泄漏-Windows LeakDiag UMDH LeakDiag的使用 UMDH的使用 gflags 设置进程 Create user mode stack trace database 安装系统调试符号 全部下载/在线下载 set _NT_SYMBOL_PATH =srv*c:\websymbols*/download/symbols umdh?-p:2230?-f:c:\Log1.txt? 资源泄漏--solaris dbx 打开check –leaks 使用libumem 使用dtrace libgc 高效自动分配/回收内存 资源泄漏--solaris dbx 1. 使用dbx启动被跟踪的程序。 $ dbx target 2. 用check -leaks打开内存泄漏检查开关。 (dbx) check -leaks 3. 运行程序直至结束。当程序运行结束时，dbx会给出检测报告 资源泄漏-solaris libumem 设置环境变量，使程序预加载li