program mac_REST_leak_test;
{$APPTYPE CONSOLE}
{$R *.res}

uses
  System.SysUtils,REST.Client,REST.Types,IPPeerClient;

var
   request : TRestRequest;
   ii,iMax : integer;
begin
   iMax := 1; 
   for ii := 0 to iMax do
   begin
      request := TRestRequest.Create(nil);
      // Fake Online REST API for Testing and Prototyping 
      request.Client := TRestClient.Create('http://jsonplaceholder.typicode.com/');
      request.Method := rmPOST;
      request.Execute();

      request.Client.Free();
      request.Free();
   end;
end.

解决方法

TCwcBasicAdapter = class(TCwcCustomAdapter)  
  protected  
    FNavTitleField: TField;  
    function GetAdapterNav(aDataSet: TDataSet): ICwcCDSAdapterNav; override;  
  public  
    constructor Create(aDataSource: TDataSource; aKeyField,aNavTitleField: TField; aMultiple: boolean);  
  end;

ICwcCDSAdapterNav = interface(IInterface)

function TCwcBasicAdapter.GetAdapterNav(aDataSet: TDataSet): ICwcCDSAdapterNav;
var
  AdapterNav: TCwcCDSAdapterNavBase;
begin
  result := nil;
  if Assigned(aDataSet) then begin
    AdapterNav := TCwcCDSAdapterNavBasic.Create(aDataSet,FKeyField.Index,FNavTitleField.Index);
    try
      AdapterNav.GetInterface(ICwcCDSAdapterNav,result);
    except
      FreeAndNil(AdapterNav);
      raise;
    end;
  end;
end;

TCwcCDSAdapterNavBase = class(TInterfacedobject,ICwcCDSAdapterNav)

解决方法

> -cpu started out at 1% and 0%. Now it is bouncing around from 2% to 5%
> -VM usage started out at 11,852KB. Now it is at 4,900kb but bouncing
> around from 4,900kb to 5,000kb.

解决方法

使用Delphi 7的WMI查询（远程）电脑时，遇到内存泄漏。 内存泄漏只发生在Windows 2003（和Windows XP 64）上。 Windows 2000是好的，Windows 2008也是如此。我想知道是否有人遇到类似的问题。

事实上，泄漏只发生在某些版本的Windows意味着它可能是一个Windows问题，但我一直在searchnetworking，一直没有能够find一个修复程序来解决问题。 另外，这可能是一个Delphi问题，因为在C＃中具有类似function的程序似乎没有泄漏。 后一个事实使我相信，在Delphi中获得所需的信息可能还有另一种更好的方式，而不会发生内存泄漏。

我已经将源代码包含在一个小程序中，以显示下面的内存泄漏。 如果sObject.Path_下面的行{ Leak! } { Leak! }注释被执行，发生内存泄漏。 如果我把它评论出来，就没有泄漏。 （显然，在“真正的”程序中，我用sObject.Path_方法调用的结果做了一些有用的sObject.Path_ 。）

用我的机器上的一个简单的Windows任务pipe理器分析，发现了以下内容：

在Linux中有没有一个MDB（模块化debugging器）solaris相当于？

在linux下运行Drupal时出现内存泄漏apache，但同样的应用程序不会在windows服务器上泄漏mem

Memory.CreateBitmapSourceFromHBitmap中的内存泄漏

这个valgrind错误是什么意思？

使用MapViewOfFile，指针最终走出内存空间

在N = 100之前N = 500 N = 1000

sObject.Path_ 3.7M 7.9M 18.2M 31.2M

没有sObject.Path_ 3.7M 5.3M 5.4M 5.3M

我想我的问题是：有其他人遇到过这个问题吗？ 如果是这样，是不是Windows的问题，是否有一个修补程序？ 或者（更可能）是我的Delphi代码被破坏了，有没有更好的方法来获取我需要的信息？

你会注意到有几次， nil是分配给对象的，与Delphi精神相反……这些是不从TObjectinheritance的COM对象，也没有可以调用的析构函数。 通过给它们分配nil ，Windows的垃圾收集器清理它们。

program ConsoleMemoryLeak; {$APPTYPE CONSOLE} uses Variants,ActiveX,WbemScripting_TLB; const N = 100; WMIQuery = ''SELECT * FROM Win32_Process''; Host = ''localhost''; { Must be empty when scanning localhost } Username = ''''; Password = ''''; procedure ProcessObjectSet(WMIObjectSet: ISWbemObjectSet); var Enum: IEnumVariant; tempObj: OleVariant; Value: Cardinal; sObject: ISWbemObject; begin Enum := (wmiObjectSet._NewEnum) as IEnumVariant; while (Enum.Next(1,tempObj,Value) = S_OK) do begin sObject := IUnkNown(tempObj) as SWBemObject; { Leak! } sObject.Path_; sObject := nil; tempObj := Unassigned; end; Enum := nil; end; function ExecuteQuery: ISWbemObjectSet; var Locator: ISWbemLocator; Services: ISWbemServices; begin Locator := CoSWbemLocator.Create; Services := Locator.ConnectServer(Host,''rootCIMV2'',Username,Password,'''',nil); Result := Services.ExecQuery(WMIQuery,''WQL'',wbemFlagReturnImmediately and wbemFlagForwardOnly,nil); Services := nil; Locator := nil; end; procedure DoQuery; var ObjectSet: ISWbemObjectSet; begin CoInitialize(nil); ObjectSet := ExecuteQuery; ProcessObjectSet(ObjectSet); ObjectSet := nil; CoUninitialize; end; var i: Integer; begin WriteLn(''Press Enter to start''); ReadLn; for i := 1 to N do DoQuery; WriteLn(''Press Enter to end''); ReadLn; end.

内存debugging器与ptrace

Qt应用程序因为内存不足（OOM）

调查内存泄漏

由激活上下文引起的dynamic加载的DLL上的文件句柄泄漏

任务pipe理器不同意Process Explorer？

我可以重现的行为，代码泄漏在Windows XP 64上的内存，而不是在Windows XP上。 有趣的是，只有在读取Path_属性的情况下，才会发生这种情况，读取Properties_或Security_具有相同的代码不会泄漏任何内存。 WMI中特定于Windows版本的问题看起来是最可能的原因。 我的系统是最新的AFAIK，所以可能没有这个修补程序。

不过，我想评论一下你重置所有的变体和接口变量。 你写

你会注意到有几次，nil是分配给对象的，与Delphi精神相反……这些是不从TObject继承的COM对象，也没有可以调用的析构函数。 通过给它们分配nil，Windows的垃圾收集器清理它们。

这是不正确的，因此不需要将变量设置nil和Unassigned 。 Windows没有垃圾收集器，所涉及的是引用计数的对象，一旦引用计数达到0，就立即销毁引用计数的对象.Delphi编译器确实会插入必要的调用，以根据需要递增和递减引用计数。 您分配给nil和Unassigned任务递减引用计数，并在对象达到0时释放该对象。

一个新的赋值给一个变量，或者退出这个过程也会照顾到这个，所以额外的赋值（虽然没有错）是多余的，降低了代码的清晰度。 下面的代码是完全等效的，不会泄漏任何额外的内存：

procedure ProcessObjectSet(WMIObjectSet: ISWbemObjectSet); var Enum: IEnumVariant; tempObj: OleVariant; Value: Cardinal; sObject: ISWbemObject; begin Enum := (wmiObjectSet._NewEnum) as IEnumVariant; while (Enum.Next(1,Value) = S_OK) do begin sObject := IUnkNown(tempObj) as SWBemObject; { Leak! } sObject.Path_; end; end;

我会说，只有在实际上释放对象的情况下才能显式重置接口（所以当前的引用计数必须是1），并且销毁本身应该确切地发生在这一点上。 后者的例子是可以释放大量内存，或者需要关闭文件或释放同步对象。

你应该存储返回值

sObject.Path_;

在一个变量中，并使其成为SWbemObjectPath。 这是使参考计数正确的必要条件。