Hat das Programm bzw. den Allocation Profiler noch keiner benutzt?
Noch nicht mit Delphi/BCB. Aber in MSVC benutze ich es öfter (meist übrigens direkt aus Visual Studio heraus, dank Plugins).
Was wichtig ist sind nicht die Einzelwerte, zumindest solange du beim Gesamtwert keine Lecks findest. Dein Programm scheint periodisch was zu machen, da sich wie du schon bemerktest die Adressen ändern (der Stack, ganz unten zeigt es ja auch deutlich: TForm2::Timer1Timer). Grob gesagt sieht es für mich aus wie einmal ein AnsiString und einmal ein UnicodeString mit dem irgendwas passiert - hast ja glücklicherweise in den beiden Screenshots jeweils ein Element der anderen Größe ausgewählt. Wichtig ist kurz unter dem roten Rahmen der Wert: 2641528 für eine schnelle Gesamteinschätzung.
Allerdings ist das nur die halbe Wahrheit, bzw. die Einsteigersicht.
Nähmen wir mal an, daß es ein Leck gäbe. In diesem Fall würdest du als erstes ein Ansteigen des o.g. Wertes feststellen. Sobald du das hast, würdest du weiterhin sehen welcher Objekttyp (und jetzt ist die Einzelauflistung wichtig) da leckt. Das ist alles aber nur wichtig, solange eine periodische Aktion stattfindet. Ansonsten sollte man zuallererst das Programm laufen lassen ... irgendwas machen was man eben so im Programm macht und es dann beenden. Dann wird man sehen, ob es schonmal unter normalen Umständen Lecks gibt - wobei AQTime ja auch auf Ressourcenlecks wie
GDI-Lecks prüfen kann (zumindest die Pro).
Interessanter finde ich bei AQTime allerdings (habe die Pro sowohl auf Arbeit als auch privat) "Platform Compliance" (statisch), "Performance Profiler" (geht bis zeilenweise Genauigkeit) und "
Exception Trace Profiler". Um Lecks zu finden eignen sich m.E.n. besser die Funktionen die ohnehin dafür zuständig sind. Also der MM bei Delphi. Und auch die CRT bei MSVC bringt schon alles mit um sowohl Speicherlecks als auch korrumpierte Heaps aufzuspüren. Für bestimmte Dinge eignet sich auch der Profiler der das Laden von DLLs überwacht. Aber hängt vom Programm ab usw. ...
Noch genialer als alles vorgenannte finde ich allerdings
Valgrind. Valgrind emuliert den Prozessor zu weiten Teilen, läuft also deutlich langsamer. Allerdings wird "tainted memory" verwendet. Jede Speicheranforderung resultiert also in einem Block der von Valgrind als noch nicht initialisiert markiert wird. Dann kann das Programm damit machen was es will, inklusive weiterkopieren usw. ...
Wenn nun Code an späterer Stelle eine Entscheidung aufgrund uninitialisierten Speichers trifft (bspw. if auf ein Array-Element), wird dies mokiert. Ob Speicher als uninitialisiert gilt, wird vererbt (also beim Kopieren von Speicher)! Desweiteren werden alle möglichen Speicherverletzungen (doppelt freigeben, Stack überschreiben, Heap überschreiben, in freigegebenen oder ohnehin nicht allozierten Speicher schreiben) angezählt und zusammen mit einem Stackdump gelistet. Der Stackdump enthält auf die Zeile genau (gcc ... -ggdb -g3) was schiefging und bei Speicherverletzungen auch die Adresse der Stelle wo der Speicher ursprünglich alloziert wurde (inkl. Stack, wenn es auf dem Stack lag). Leider gibt es Valgrind nur für unixoide Systeme und es setzt DWARF-Debuginfos voraus. Aber bei plattformunabhängigem Code habe ich bisher noch nichts besseres gefunden.