1

To provide as much information as I can, here's a very basic example of what I'm doing

type
  IMyInterface = interface
  [THE_GUID_HERE]
    // some methods
  end;

  TMyInterfaceArray = Array of IMyInterface;

  TMyInterfacedObject = class(TInterfacedObject, IMyInterface)
    // implementation of the Interface etc. here
  end;

  TContainingObject = class
  private
    FIObjectArray: TMyInterfaceArray;
  public
    constructor Create;
    destructor Destroy; override;
    procedure NewInstanceOfInterfacedObject;
  end;

  implementation

  constructor TContainingObject.Create;
  begin
    inherited;
    // Just to illustrate that an Instance is being created...
    NewInstanceOfInterfacedObject;
  end;

  destructor TContainingObject.Destroy;
  var
    I: Integer;
  begin
    for I := Low(FIObjectArray) to High(FIObjectArray) do
      FIObjectArray[I] := nil;
    SetLength(FIObjectArray, 0); // Array collapsed

    inherited;
  end;

  procedure TContainingObject.NewInstanceOfInterfacedObject;
  var
    LIndex: Integer;
  begin
    LIndex := Length(FIObjectArray);
    SetLength(FIObjectArray, LIndex + 1);
    FIObjectArray[LIndex] := TMyInterfacedObject.Create;
  end;

Okay, so an instance of TContainingObject is created, and in turn creates an instance of TMyInterfacedObject, stored in an Array of IMyInterface.

When TContainingObject's destructor is called, it nil's the reference and collapses the Array.

The issue I have is that, with no other references anywhere, TMyInterfacedObject's destructor is never called, and thus memory leaks.

Am I doing something wrong, or is Delphi's reference counting system not able to cope with the simple concept of Interfaced Objects being held in an Array of the Interface Type?

Thanks for any advice!

MORE INFORMATION

TContainingObject provides an Array property to access individual instances of IMyInterface contained within the Array.

In my actual code, there are circular references between multiple Interface types. Let's suggest that IMyInterface contains a function GetSomething: IAnotherInterface, and IAnotherInterface contains GetMyInterface: IMyInterface (a circular reference). Could this be causing my problem? If so, the circular reference is absolutely required, so what would a solution be with that in mind?

LaKraven
  • 5,804
  • 2
  • 23
  • 49
  • 1
    Do you have the same problem with a TInterfaceList instead of an array? – Nathanial Woolls Apr 03 '12 at 00:02
  • I have never looked at TInterfaceList. I'll take a look now, but I really would prefer to use a simple Array (to take advantage of my existing "Managed Array" systems) – LaKraven Apr 03 '12 at 00:06
  • Okay... supplemented my Array for `TInterfaceList`, and the result is exactly the same: `destructor` of `TMyInterfacedObject` is never called, memory leaks! – LaKraven Apr 03 '12 at 00:18
  • Then you are doing something wrong in code you have not shown, because the code you did show works fine. The destructor is called as expected. – Remy Lebeau Apr 03 '12 at 00:23
  • The only other thing is that `TContainingObject` in my actual code has an Array Property to access instances held in the Interface Array. – LaKraven Apr 03 '12 at 00:25
  • Is the property using direct access to the array, or getter/setter methods? – Remy Lebeau Apr 03 '12 at 00:47
  • @RemyLebeau getter/setter methods – LaKraven Apr 03 '12 at 00:53

2 Answers2

5

If the implementation for IMyInterface contains an IAnotherInterface member, and the implementation for IAnotherInterface contains an IMyInterface member, and they refer to each other, then their reference counts will never be able to fall to 0 unless you clear one of the references, which likely means adding methods to your interfaces to do that, eg:

type
  IAnotherInterface = interface;

  IMyInterface = interface
  ['{guid}']
    function GetAnotherInterface: IAnotherInterface;
    procedure SetAnotherInterface(Value: IAnotherInterface);
    property AnotherInterface: IAnotherInterface read GetAnotherInterface write SetAnotherInterface;
  end;

  IAnotherInterface = interface
  ['{guid}']
    function GetMyInterface: IMyInterface;
    procedure SetMyInterface(Value: IMyInterface);
    property MyInterface: IMyInterface read GetMyInterface write SetMyInterface;
  end;

.

type
  TMyInterface = class(TInterfacedObject, IMyInterface)
  private
    FAnotherInterface: IAnotherInterface;
  public
    function GetAnotherInterface: IAnotherInterface;
    procedure SetAnotherInterface(Value: IAnotherInterface);
  end;

  TAnotherInterface = class(TInterfacedObject, IAnotherInterface)
  private
    FMyInterface: IMyInterface;
  public
    function GetMyInterface: IMyInterface;
    procedure SetMyInterface(Value: IMyInterface);
  end;

  function TMyInterface.GetAnotherInterface;
  begin
    Result := FAnotherInterface;
  end;

  procedure TMyInterface.SetAnotherInterface(Value: IAnotherInterface);
  begin
    if FAnotherInterface <> Value then
    begin
      if FAnotherInterface <> nil then FAnotherInterface.SetMyInterface(nil);
      FAnotherInterface := Value;
      if FAnotherInterface <> nil then FAnotherInterface.SetMyInterface(Self);
    end;
  end;

  function TAnotherInterface.GetMyInterface: IMyInterface;
  begin
    Result := FMyInterface;
  end;

  procedure TAnotherInterface.SetMyInterface(Value: IMyInterface);
  begin
    if FMyInterface <> Value then
    begin
      if FMyInterface <> nil then FMyInterface.SetAnotherInterface(nil);
      FMyInterface := Value;
      if FMyInterface <> nil then FMyInterface.SetAnotherInterface(Self);
    end;
  end;

Now watch the reference counts when you don't explicitally free one of the references:

var
  I: IMyInterface;
  J: IAnotherInterface;
begin
  I := TMyInterface.Create; // I.RefCnt becomes 1
  J := TAnotherInterface.Create; // J.RefCnt becomes 1
  I.AnotherInterface := J; // I.RefCnt becomes 2, J.RefCnt becomes 2
  ...
  {
  // implicit when scope is cleared:
  I := nil; // I.RefCnt becomes 1, I is NOT freed
  J := nil; // J.RefCnt becomes 1, J is NOT freed
  }
end;

Now add an explicit release to one of the references:

var
  I: IMyInterface;
  J: IAnotherInterface;
begin
  I := TMyInterface.Create; // I.RefCnt becomes 1
  J := TAnotherInterface.Create; // J.RefCnt becomes 1
  I.AnotherInterface := J; // I.RefCnt becomes 2, J.RefCnt becomes 2
  ...
  I.AnotherInterface := nil; // I.RefCnt becomes 1, J.RefCnt becomes 1
  {
  // implicit when scope is cleared:
  I := nil; // I.RefCnt becomes 0, I is freed
  J := nil; // J.RefCnt becomes 0, J is freed
  }
end;

.

var
  I: IMyInterface;
  J: IAnotherInterface;
begin
  I := TMyInterface.Create; // I.RefCnt becomes 1
  J := TAnotherInterface.Create; // J.RefCnt becomes 1
  I.AnotherInterface := J; // I.RefCnt becomes 2, J.RefCnt becomes 2
  J := nil; // I.RefCnt still 2, J.RefCnt becomes 1, J is NOT freed yet
  ...
  I.AnotherInterface := nil; // I.RefCnt becomes 1, J.RefCnt becomes 0, J is freed
  {
  // implicit when scope is cleared:
  I := nil; // I.RefCnt becomes 0, I is freed
  }
end;
Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
  • I just looked at the issue over Skype, and that's it, Remy! He's having circular references! – chuacw Apr 03 '12 at 01:27
0

When I run your code example in Delphi XE2 (after fixing a small typo - see edit), it runs just fine for me and calls the TMyInterfacedObject destructor as expected.

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
  • This is why I'm so confused! I'm doing a similar thing in other code and it works fine, yet in this particular unit and one other (in two separate projects), the destructor is never being called! – LaKraven Apr 03 '12 at 00:23
  • @LaKraven could not be different project options or compiler directives for this unit? – EMBarbosa Apr 03 '12 at 00:40
  • @EMBarbosa no. There are no special conditions, directives, settings or any other such thing... it is a standard unit, in a standard project with default project options. – LaKraven Apr 03 '12 at 00:42
  • The only way the destructor would not be called is if the interface's reference count is not falling from 1 to 0. Use the debugger to step through the RTL code to find out what the reference count is really doing in the units that are not working correctly. – Remy Lebeau Apr 03 '12 at 00:46