为什么我的程序会泄漏虚拟内存?

发布于 2024-10-23 14:39:39 字数 950 浏览 4 评论 0原文

为了寻找内存泄漏,我一直在使用 MemProof,并且能够查看正在使用、创建和销毁的资源的实时计数。在运行我的程序一天半后,我注意到其他一切都保持不变或更少,虚拟内存(VM)的数量正在增加。一开始是 109,24 小时后现在是 113。

这就是 MemProof 对每个虚拟机泄漏的说法:

VirtualAlloc(address_location, 16384, 4096, 4);它被标识为虚拟内存,其大小始终为 16384。API 名称为 VirtualAlloc。该模块是kernel32.dll。

此外,memproof 表示,“virtualalloc 在调用进程的虚拟地址空间中保留或提交一个页面区域。当不再需要时,必须使用 virtualFree 释放已分配的页面。”

VM 泄漏与文件 System.Pas 中的函数相关。

功能如下:

function GetCmdShow: Integer;
var
  SI: TStartupInfo;
begin
  Result := 10;                  { SW_SHOWDEFAULT }
  GetStartupInfo(SI);
  if SI.dwFlags and 1 <> 0 then  { STARTF_USESHOWWINDOW }
    Result := SI.wShowWindow;   
end;  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

我有小于号指向关键字“end”,当我单击虚拟内存泄漏时,Memproof 将我带到这里。

那么,这意味着什么呢?

In search of memory leak, I have been using MemProof and be able to see live counts of resources being used, created and destroyed. After having run my program for over a day and half, I have noticed that everything else being constant or less, Virtual Memory (VM) is increasing in counts. It started out at 109 and now it is at 113 after 24 hours.

This is what MemProof says for each VM leak:

VirtualAlloc(address_location, 16384, 4096, 4); It is identified as Virtual Memory and its size is always 16384. API name is VirtualAlloc. The module is kernel32.dll.

Furthermore, memproof says, "virtualalloc reserves or commits a region of pages in the virtual address space of the calling process. Allocated pages must be freed with virtualFree when no longer needed."

VM leak is associated with a function in the file System.Pas.

The function is as follows:

function GetCmdShow: Integer;
var
  SI: TStartupInfo;
begin
  Result := 10;                  { SW_SHOWDEFAULT }
  GetStartupInfo(SI);
  if SI.dwFlags and 1 <> 0 then  { STARTF_USESHOWWINDOW }
    Result := SI.wShowWindow;   
end;  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

I have the less than signs pointing at the key word "end" is where Memproof takes me to when I click on virtual memory leak(s).

So, what does this mean?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

抠脚大汉 2024-10-30 14:39:39

Delphi 的 FastMM 内存管理器在 Windows 内存系统之上工作。它使用 VirtualAlloc 从操作系统分配大内存块,然后将其分成更小的块供程序使用。如果释放大量内存,它会将其中一部分返还给操作系统。但是,如果您释放少量内存,它可能会保留下来,因为您可能很快会再次需要它。这是 FastMM 快速的部分原因,而且它不是内存泄漏。

任何只监视 VirtualAlloc 而实际上不关注 FastMM 正在做什么的内存分析器都会给您带来没有意义的结果。正如 David 在评论中提到的,如果你想追踪真正的内存泄漏,你需要使用 FastMM 工具。从 SourceForge 下载 FastMM 的完整版本并阅读文档以了解如何启用 FullDebugMode 以及泄漏报告和日志记录,您将获得更轻松的体验。

Delphi's FastMM memory manager works on top of the Windows memory system. It allocates large blocks of memory from the OS with VirtualAlloc, and then divides that up into smaller chunks for your program to work with. If you free large amounts of memory, it will give some of it back to the OS. If you free small amounts of memory, though, it's likely to hold on to it because you're likely to need it again soon. This is part of what makes FastMM fast, and it's not a memory leak.

Any memory profiler that only watches VirtualAlloc and doesn't actually pay attention to what FastMM is doing is going to give you results that don't make sense. As David mentioned in the comment, if you want to track down real memory leaks, you need to use the FastMM tools. Download the full version of FastMM from SourceForge and read the documentation to find out how to enable FullDebugMode and leak reporting and logging, and you'll have a much easier time of it.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文