以下内容是转自 http://www.cnblogs.com/fbird/p/5889596.html
以前做项目碰到过一个问题,在客户的站点上面发现有严重的内存泄漏。幸运的是我们找到了重现的步骤,一轮下来大概有几十兆的泄漏,但是以下常规方法却没啥用。
- 用windbg把heap上面的object全部dump下来,和上一轮操作作比较,并不能发现什么有用的东西。
- 大对象heap上面也没啥有用的东西。
- 像.net memory profiler这种比较智能的工具也用不上,因为一轮操作下来已经能使工具out of memory。
项目有几百万行代码,但是我们认为可能发生大内存泄漏的就几个点。把那几个点的代码都找了一遍,没有任何结果。左寻右找,终于找到了一种比较笨但是却很管用的方法。
1. 打开Windbg, attach进程。
2. 加载symbol
3. 打断点 (可以用.logopen c:\memoryleak.txt把log记下来)
bp kernel32!virtualalloc ".printf\"#alloc memory# %lu \\n \",dwo(esp+8);!clrstack;g;" |
4. 输入g然后回车让进程继续跑。
5. 将重现步骤跑一遍,然后去review日志。
接下来的过程比较笨,Review日志的过程中找到比较可疑的申请大块内存的点,注释代码,编译Assembly替换,看内存泄漏还在不在。最终还是找到了那个泄漏的地方,一个remoting的proxy,出了作用域但是其指向的内存去没有被自动释放。
解决这个问题的最关键的就是下面这条命令:
bp kernel32!virtualalloc ".printf\"#alloc memory# %lu \\n \",dwo(esp+8);!clrstack;g;"
它的作用就是在kernel32的virtualalloc函数上面打断点,当该函数被执行到的时候,就把该函数申请的内存数量(在esp+8这个位置,dwo是把这个里面的值转成十进制),以及调用该函数的托管栈(clrstack)打印出来,然后让函数继续跑(g)。
需要说明的是,这个命令仅对32位进程有效,因为根据32位cpu的calling convention,esp+4是第一个参数位置,esp+8是第二个,以此类推。64位的进程要去再查一下对应的calling convention看相关参数在哪个位置。
LPVOID WINAPI VirtualAlloc(
_In_opt_ LPVOID lpAddress,
_In_ SIZE_T dwSize,
_In_ DWORD flAllocationType,
_In_ DWORD flProtect
);