3

I've had some problems with FastMM false positives. This time, the leaks are in the cases testing forms. It's very similar to the one I described here.

I got a form and some plain old VCL controls in it. The first test run shows leaks which, in fact, doesn't exists. The second run gets no leaks. I've searched over all DUnit source code, but couldn't find the reason in order to fix it. Can somebody help me?

I can't afford to run the test twice because: 1. It will be run in a continuous integration; 2. Some tests really take some time and doubling it wouldn't be wise.

I checked the last 3 options in the DUnit GUI: - Report memory leak type on Shutdown - Fail TestCase if memory leaked - Ignore memory leak in SetUp/TearDown

Here are the sample codes:

    // form
    type

    TForm2 = class(TForm)
      button1: TButton;
    end;

    implementation

    {$R *.dfm}

    // test
    type

    TTest = class(TGUITestCase)
    private
      a: TForm2;
    public
      procedure SetUp; override;
      procedure TearDown; override;
    published
      procedure Test;
    end;

    implementation

    procedure TTest.Setup;
    begin
      a := TForm2.Create(nil);
    end;

    procedure TTest.TearDown;
    begin
      FreeAndNil(a);
    end;

    procedure TTest.Test;
    begin
      a.Show;
      a.close;
    end;
Community
  • 1
  • 1
Rafael Castro
  • 101
  • 7
  • 1
    Tried to reproduce the memleak with your sample code, but with the latest dunit, and fastmm (with delphi 7) I found no leaks. What's in the fastmm report file? Also try set under Project options the Map file to detailed, Include TD32 debug info, and check Use Debug Dcu-s, for a detailed report. – balazs Sep 03 '12 at 22:09
  • @balazs there's no report generated. Can you point me the links to the DUnit and FastMM versions you used? Thanks! – Rafael Castro Sep 24 '12 at 17:36
  • Sure, [dunit](http://dunit.sourceforge.net/), the last version is 9.3 at the time of writing this comment, [fastmm4](http://sourceforge.net/projects/fastmm/), version 4.9.9.1. In FastMM4Options.inc switch on FullDebugMode (`{$define FullDebugMode}`), and copy the `FastMM_FullDebugMode.dll` next to the exe file. – balazs Sep 25 '12 at 15:26
  • @balazs sorry pal, but used both and the error persisted. Just to be sure: I checked the last 3 options on DUnit GUI: Report memory leak, Fail TestCase if leaked and Ignore leaks in Setup/Teardown. Thanks. – Rafael Castro Oct 31 '12 at 10:53
  • Ahh, I didn't used the built in fastmm of dunit, I put manually fasmm4 to the first place of my project uses list, and don't define fastmm, in the conditional defines list of your project. than edit the FastMM4Options.inc and set project options. Use fastmm4 as you would use in a regular (not dunit) project. [here](http://wiert.me/2009/07/29/delphi-fastmm-using-fastmm4-for-debugging-your-memory-allocations-part-1-introduction/)'s a good writeup – balazs Oct 31 '12 at 11:13

2 Answers2

4

You're free'ing the form twice. Setting the action to caFree makes the form free itself automatically. So either you remove the OnClose method or even better you create the form in the test itself and remove the setup and teardown methods without freeing the form. CaFree will take care of that.

Brave Cobra
  • 684
  • 3
  • 11
0

With the downloaded version the situation ocurred ocasionaly. As absurd as it seems, the root cause is: if I hit "F9" too fast after DUnit GUI is loaded, the problem occurs. Waiting few seconds, no leaks are reported.

Since here we overriden the FormShow event to automatically start the tests, in my case the problem always occurred. So, delaying the execution by 2 seconds solved my problem.

Thanks @balazs for helping me out.

Rafael Castro
  • 101
  • 7