Chinaunix首页 | 论坛 | 博客
  • 博客访问: 2359126
  • 博文数量: 527
  • 博客积分: 10343
  • 博客等级: 上将
  • 技术积分: 5565
  • 用 户 组: 普通用户
  • 注册时间: 2005-07-26 23:05
文章分类

全部博文(527)

文章存档

2014年(4)

2012年(13)

2011年(19)

2010年(91)

2009年(136)

2008年(142)

2007年(80)

2006年(29)

2005年(13)

我的朋友

分类: WINDOWS

2008-07-08 00:41:07

PurifyPlus 检测native C/C++代码中的内存漏泄相关的问题十分有用, 但在下面情形中只能使用部分检测一个native DLL的功能:

1. 主程序是.NET maganged代码.
   虽然PurifyPlus也可以检测.NET 代码中的问题, 但是实际使用中发现启动程序是.NET managed exe文件的情况下, 往往启动程序就会失败, 本来因为这个就不能处理我们项目中的C/C++内存问题了, 后来在IBM网站查到一篇文章, 这篇文章贡献给了我一个贼长贼长的环境变量(IBM_RATIONAL_PURIFY_ENABLE_SELECTIVE), 把它的值设置在1, 就可以手工指定一个程序中的DLL在它的监控之下.

2. 调用了某个/某些native的C/C++写的代码

这种情况下我们发现 PurifyPlus 报告一块内存为UMR: Uninitialized memory read, 说一块内存还没初始化就去读取其中内容. 一开始没有细想这个问题, 检查代码, 调试跟踪, 都证明这块内存确确实实被初始化了, 初始化的代码是通过fread调用一次性读入文章的内容, 直接填满了整个目标内存, 由于fread调用的返回值没有检查, 继而怀疑是文件长度不够, 没有读入足够的内容到目标内存, 检查了fread的返回值, 证明是正确的.

问题在于上述办法来监控某个DLL时, 所关心的仅限于该DLL本身, 对这块内存的读取发生在这个DLL地址空间内, 但对它的写操作却是由fread完成的, 显然是由系统的DLL提供的功能实现的. 由于系统的这个DLL没有受到PurifyPlus的监控, 所以它无法截获对这块内存的写操作, 也就是初始化.

表面看起来是误报. 其实是这种用法本身造成的. 在刚刚分配了上述目标内存之后马上用memset 清0, 警告消失.
阅读(873) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~