Automation object leaks memory (TConnectionPoints)

I have an automation object with event support that leaks memory. The FConnectionPoints which comes with the generated source is never freed. When I manually add FConnectionPoints.Free in the destructor, the leak goes away.

I am on Delphi 7, using a FastMM BorlandMM.dll and FastMM_Fulldebugmode.dll.

Steps to reproduce:

1. Start a new ActiveX Library project
2. Add a new Automation Object: Name = TestObject; Check "Generate Event support code"
3. Open the TypeLibrary, add a method to ITestObject, add an event to ITestObjectEvents
4. Refresh, code will be generated.
5. Add ShareMem as the first unit in your .dpr file
6. Save, compile and register this ActiveX Server (Run menu)
7. Start a new Application project
8. Put ShareMem as the first unit in your .dpr file
9. Import Type Library unit: create the unit from the dll you've just created in step 6, and check "Generate Component Wrapper"
10. In your FormCreate add the following code:

code:

var
  lTest: T开发者_JAVA百科TestObject;
begin
  lTest := TTestObject.Create(nil);
  try
    lTest.ConnectKind := ckNewInstance;
    lTest.Connect;
    lTest.Disconnect;
  finally
    lTest.Free;
  end;
end;

Now compile, run and close this application. A memoryleak will be reported.

Question:

Is this a bug in the Delphi code template, am I doing someting wrong, or is it intended to free FConnectionPoints yourself (the help doesn't mention it)?

I don't fully understand the question as I never worked with automation objects but as far as I can see IConnectionPoint is an interface. Interfaces in Delphi are reference-counted (if the implementation inherits from TInterfacedObject, TContainedObject or TAgreggatedObject or implements _AddRef and _Release accordingly), so there should be no memory leak.

For more information on interfaces look at this article.

This chapter from the Delphi Language Guide could help too.

I found this issue to be reported in Quality Central report #1480.

A Sysop asked me to create a new report so I did: report #81288.

This also answers my question: it is a bug in the code template.