经典 ASP 应用程序中的内存泄漏
我最近继承了一个经典ASP网站的维护，我以前从未做过经典ASP，所以如果我问了一些愚蠢的问题，请原谅我。
我的合作开发人员已经检查了每个页面，以确保 sql 连接已关闭，集合已清空，然后设置为 null。然而，这是一个很大的网站，显然我们错过了一些东西。
我有一个进程泄漏时的转储（由调试诊断获取）。当我使用 debug diag 执行内存分析时，它通知我尚未检测到 LeakTrack.dll，因此无法执行泄漏分析。
我使用 Windbg 打开转储，发现一个堆比其他堆大得多，其中 90% 的内存都在一个堆中。然而，当我尝试将块跟踪回分配它们的调用堆栈时，我总是会得到以下结果：
invalid allocation size, possible heap corruption
是否有更好的方法来尝试跟踪泄漏何时发生？或者您对如何创建更好的进程转储有任何建议，以便我可以检查泄漏来自何处？
I have recently inherited the maintenance of a classic ASP website, I've never done classic ASP before, so please forgive me if I'm asking daft questions.
My co-developers have already been through each and every page to make sure that sql connections are closed, collections are emptied and then set to null. However, it's a large site, clearly between us we've missed something.
I have a dump of the process when it was leaking (taken by debug diag). When I use debug diag to perform it's memory analysis it informs me that has not detected LeakTrack.dll so is unable to perform leak analysis.
I have opened up the dump using windbg and have found one heap that is much larger than the others, with 90% of the memory in one heap. However, when I try to track the blocks back to the call stacks that allocate them I always end up with:
invalid allocation size, possible heap corruption
Is there a better way to try and track when the leak is coming from? Or do you have any tips on how to create a better process dump so that I can inspect where the leaks are coming from?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这些泄漏持续超过一个页面？页面完成后，所有页面本地的内容都应该被清理并释放。在不了解有关您的应用程序的更多信息的情况下，我建议您查看更长期喜爱的对象。您是否在会话或应用程序中存储任何内容？
These leaks last beyond a single page? All page-local stuff should be cleaned up and deallocated once the page is finished. Without knowing more about your application, I'd suggest looking at longer-loved objects. Are you storing anything in Session or Application?