Delphi application leaking AnsiStrings

Question

According to FastMM4, the Delphi program I'm working on at the moment is leaking a lot strings. AnsiStrings to be precise:

The application (http://sourceforge.net/projects/orwelldevcpp/) used to leak a lot more other data types, but FastMM4 could report where the instance was created, so I managed to fix that. The strange thing is that FastMM4 doesn't report locations of these leaks at all.

Edit: it seems it does after all, see answers for the fix. Anyways, the question still stands: how in the world am I leaking these things?

So, ehm, unfortunately, I've got no idea what to look for. I mean, if these things go out of scope, they should be automatically freed right (even though they're on the heap)?

I did manage to track a few leaks down by random commenting and seeing what would happen to the counts. Here's an example:

// simply passing it a constant creates a leak...
MainForm.UpdateSplash('Creating extra dialogs...');

procedure TMainForm.UpdateSplash(const text : AnsiString);
begin
  if not devData.NoSplashScreen then // even if this branch is NOT taken
    SplashForm.Statusbar.SimpleText := 'blablabla' + text;
end;

// And even if the function call itself is placed within a NOT taken branch!

Here's another example of a leak:

// Passing this constants produces leaks...
procedure TCodeInsList.AddItemByValues(const a, b, c: AnsiString;...);
var
  assembleditem : PCodeIns;
begin
   new(assembleditem);
   assembleditem^.Caption:=a;
   assembleditem^.Line:=b;
   assembleditem^.Desc:=c;
   ...
   fList.Add(assembleditem);
end;

// ... even when calling this on WM_DESTROY!
destructor TCodeInsList.Destroy;
var
  I: integer;
begin
  for I := 0 to fList.Count - 1 do
    Dispose(fList[I]);
  fList.Free;
  inherited Destroy;
end;

// produces leaks!?

There are quite a bunch of string leak questions here, but none really clarify what patterns one should look for. Google doesn't provide either.

Edit: so, I have to look for passed constants. But why?

So ehm, any ideas?

Answer 1

You don't need to be explicitly allocating strings. Apart from mangling with reference counts, string fields of objects or records may also leak. For instance,

type
  PRecord = ^TRecord;
  TRecord = record
    S: string;
  end;

procedure TForm1.Button4Click(Sender: TObject);
var
  r: PRecord;
begin
  GetMem(r, SizeOf(r^));
  Initialize(r^);
  r.S := ' ';
  FreeMem(r);

In the above example, since the memory of the record itself is freed, FastMM will report only the leaked string.

In any case, FastMM not showing a stack trace in the dialog does not mean that it lacks that information. Be sure to have FullDebugMode, LogMemoryLeakDetailToFile and LogErrorsToFile are defined in 'FastMM4Options.inc'. Then look for a '[ExecutableName]_MemoryManager_EventLog.txt' file in the directory of the executable.

For the above example, FastMM produces the following file:

--------------------------------2012/5/27 4:34:46--------------------------------
A memory block has been leaked. The size is: 12

Stack trace of when this block was allocated (return addresses):
40305E 
404B5D 
404AF0 
45C47B 
43D726 
42B0C3 
42B1C1 
43D21E 
76C4702C [GetWindowLongW]
77AE3CC3 [Unknown function at RtlImageNtHeader]

The block is currently used for an object of class: Unknown

The allocation number is: 484

Current memory dump of 256 bytes starting at pointer address 7EF8DEF8:
01 00 00 ...
...

Now you can run the application, pause it and then search for the addresses. For the above log and the test application, the addresses resolves to:

Stack trace of when this block was allocated (return addresses):
40305E    -> _GetMem
404B5D    -> _NewAnsiString
404AF0    -> _LStrAsg
45C47B    -> TForm1.Button4Click (on FreeMem line)
43D726    -> TControl.Click
... 

edit: Instead of manually looking up addresses, generate a detailed map file through linker options and FastMM will do it (thanks to Mason's comment).

---

Your edit on the question reflects a quite similar leak like the one in the above example. If the 'fList' is a regular TList, it just holds pointers and have no knowledge of what those pointers points to. Hence when you dispose the pointer, just the memory allocated for the pointer itself is freed, not the fields of the record. So the leaks have nothing to do constants passed to functions but is like the pattern below:

var
  assembleditem: PCodeIns;
  p: Pointer;
begin
  new(assembleditem);
  assembleditem^.Caption:='a';
  ..    
  p := assembleditem;
  Dispose(p);

For the record to be disposed, the code should typecast the pointer to its type:

Dispose(PCodeIns(p));

So your 'TCodeInsList.Destroy' should be:

destructor TCodeInsList.Destroy;
var
  I: integer;
begin
  for I := 0 to fList.Count - 1 do
    Dispose(PCodeIns(fList[I]));
  fList.Free;
  inherited Destroy;
end;

In the end, the pattern you're looking for seems to be looking for places where the code intents to free records (less likely objects) having string fields. Looking for Dispose, a little less likely FreeMem, even less likely FreeInstance to free memory of objects/records that FastMM shows as the allocated memory is leaked could help.