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?
Practice As Follows
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
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 ...
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:
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.