Does madExcept resource leak reporting support [weak] att?

delphi package - automated exception handling
Post Reply
santiago
Posts: 73
Joined: Thu May 05, 2016 6:01 pm

Does madExcept resource leak reporting support [weak] att?

Post by santiago »

Hi madschi,

Starting with Delphi Berlin (10.1) the desktop compiler now also supports weak references.
You can read more about it here.
http://blog.marcocantu.com/blog/2016-ap ... ences.html.

Since we upgraded to Tokyo, I changed a few places where we were using Pointers to avoid circular references to use the new [weak] attribute instead.

However when I closed our app, madExcept reported memory leaks. According madExcept the leaks occur at the location where I changed the pointer to a weak reference.

So I started looking into it.

First I created a Unit Test. The test passes -> this means the [weak] attribute is working as expected.
If I comment out the [weak] attribute the test fails.

Code: Select all

procedure TTestWeakReferences.TestWeakReference;
var
  Instance: ITestClass;
  StrongReference: ITestClass;
  [weak]
  WeakReference: ITestClass;
begin
  Instance := TTestClass.Create;
  CheckRefCount(Instance, 1);

  // strong reference -> RefCount must increase
  StrongReference := Instance;
  CheckRefCount(Instance, 2);

  // weak reference -> RefCount must NOT change!
  WeakReference := Instance;
  CheckRefCount(Instance, 2);

  // decrease RefCount by 1 -> WeakReference should still be valid
  StrongReference := nil;
  CheckNotNull(WeakReference);

  // release all strong references -> object will be freed -> WeakReference should be set to nil
  Instance := nil;
  CheckNull(WeakReference);
end;
Then I even added a runtime check, where the [weak] attribute is used.
FParent is declared as:
[Weak] FParent: IJobComponent;

Exception does not fire. It does fire if I comment out the [weak] attribute.
So this is more proof, that the weak attribute is working as expected.

Code: Select all

procedure TJobComponent.SetParent(const Value: IJobComponent);
var
  RefCount1: Integer;
  RefCount2: Integer;
begin
  if Assigned (Value) then
    RefCount1 := (Value as TInterfacedObject).RefCount;

  FParent := Value;

  if Assigned (Value) then
  begin
    RefCount2 := (Value as TInterfacedObject).RefCount;
    if RefCount1 <> RefCount2 then
      raise Exception.Create(Format('Weak refrence failure for: [%s]. Before: %d. After: %d.', [(Value as TObject).ClassName, RefCount1, RefCount2]));
  end;
end;
Therefore the question, could it be that madExcept does not yet handle/support weak attributes and is reporting false positives?

Thank you!
santiago
Posts: 73
Joined: Thu May 05, 2016 6:01 pm

Re: Does madExcept resource leak reporting support [weak] at

Post by santiago »

Hello madschi,

We also use FastMM for leak reporting. It was reporting the same leaks as madExcept.
While looking into the problem I ran into the following: http://www.delphipraxis.net/189654-fast ... elphi.html
So I enabled the FastMM NeverUninstall option as recommended in that thread.

FastMM stopped reporting the weak references as leaks, great! :-)
But to my surprise so did madExcept. The only change I did was activate the NeverUninstall option.

Anyhow I then built in a few leaks to make sure leak detecting/reporting was working.
And sure enough, both FastMM and madExcept reported the leaks.

So everything seems fine now, am just surprised as to why the FastMM Option affected madExcept.
Would be grateful if you have any idea as to why that is.

Thx!
madshi
Site Admin
Posts: 10749
Joined: Sun Mar 21, 2004 5:25 pm

Re: Does madExcept resource leak reporting support [weak] at

Post by madshi »

madExcept's leak reporting is relatively clever. Unlike my competition :) madExcept should be able to only report true leaks, regardless of in which order the units are finalized.

My best guess is that when using FastMM without the NeverUninstall option, the leaks reported by madExcept are actually true leaks, because FastMM is finalized/uninstalled too early, and the RTL tries to free some stuff after FastMM is already finalized, which then fails. So basically using the NeverUninstall option not only "hides" the leaks, it actually fixed them. This is just a guess, though, I haven't really investigated this in full detail.
Post Reply