Wie kann man ein "halbes" Memory-Leak finden?

[DGL-luke]

schon lange nicht mehr delphifoniert, mal sehn ob ich meine ad hoc array-allokationsverwaltung noch zusammenkrieg:

Delphi-Quellcode:

var firstfree: integer;
    array: array of Typ;

function ArrayAdd(val: Typ): TResult;
begin
  if high(Array) < firstfree then
    setlength(array, length(array) * 162 div 100); //1.62 = magic number; feintunen sorgt evtl. für bessere performance je nachdem wie das array wachsen soll

  array[firstfree] := val;
  Inc(firstfree);
end;

is jetzt aus dem stegreif getippt und sicher auch algorithmisch nicht optimal. sollte speicherfragmentation aber vorbeugen, denn das array wird immer um einen bestimmten faktor vergrößert, d.h. je größer es wird, desto seltener muss es vergrößert werden.

TList ist aber evtl. wirklich sinnvoller! (wobei ich da nicht weiß wie optimal der array da drin behandelt wird)

[Phoenix]

Nein, ich benutze kein Com (zum Glück).

@Kapselung: Die Arrays sind gekapselt.
Ich dachte, das wäre Performancetechnisch ein Vorteil, meine Datenstrukturen in dynamischen Arrays zu verwalten, damit ich nicht den Overhead der Objektverwaltung habe an der Stele. Insbesondere wenn viel darauf gearbeitet wird.

Von daher ist das Umstellen auf TList / TObjectList auch nicht so der Riesen aufwand. Ich muss halt das array of in eine TObjectList ändern und die drei Methoden (reinpacken, rausholen, löschen) anpassen. Das halt in einigen klassen, aber so wild ist das nicht.

Aber wenn FastMM an der Stelle die Fragmentierung schonmal von sich aus zumindest eindämmen könnte, dann würde ich erstmal an deren Stellen suchen und ein Tracing für meine Datenbäume einbauen um zu sehen, wann ich da genau was drin habe und wann sich was ändert.

[generic]

Nutzt du Handels direkt?
(Filehandles, Fensterhandels usw.)

[Phoenix]

Nein, das sind keine Ressourcen. Das sind 'nur' ein haufen Objekte die ne Handvoll Daten bereitstellen, die ich in einer Art Tree verwalten muss, um da mittels Pointer-Operationen möglichst schnell drauf zugreifen zu können.

Das können halt schnell ein paar zigtausend Objekte werden, auf die ich im Worst-Case verdammt schnell zugreifen können muss. Und wenn sich an der Datenquelle was ändert, dann ändert sich halt auch ggf. der Aufbau des Trees. Und ich befürchte fast, dass ich in so einem Fall einfach irgendwo vergesse, alte, nicht mehr benötigte Objekte aufzuräumen. Die bleiben halt einfach in dem Tree hängen, aber auf diese Äste wird nie mehr zugegriffen. Am Ende wird logischerweise der ganze Baum aufgeräumt, deswegen bleiben diese Objekte auch ned liegen.

[DGL-luke]

na dann lass doch mal das großreinemachen am ende weg. da wird dir das zeug schon ordentlich um die ohren fliegen :) und alle MMs mit leak-reporting (FastMM ist da echt gut!) werden dir zeigen, welche objekte da noch rumlunger,n evtl. sogar mit Klassenname und speicherbereich und zeilennummern, wo die objekte erzeugt wurden :)

EDIT: du kannst das natürlich auch selber machen. in die basisklasse deiner objekte (du hast sowas hoffentlich?) ein field lineofcreation: integer rein, Strg+F, ".Create", und überall zuweisen bei erstellung, und am ende alles was noch im tree hockt durchiterieren und schreien lassen.

[Phoenix]

Zitat:

Zitat von DGL-luke

na dann lass doch mal das großreinemachen am ende weg.

Dann hab ich tausende Objekte da drin, von denen ich weiss dass ich sie erst am Ende aufräumen muss.

Bei den tausenden dann ggf. genau die zig Objekte zu finden, die da nicht reingehören... das ist leider Utopisch.

[DGL-luke]

gut, dann siehe mein edit, und zusätzlich noch ein bool "lazyObject" dazu (faul=liegt bis zum ende rum ;-))

EDIT: evtl. sogar als class const...

[Phoenix]

Ich hab einige zigtausende Objekte, die ich definitiv bis zum Ende brauche. Da ist nix Lazy.
Zudem ergibt sich das Problem nur dann, wenn die Anwendung eine ganze Zeit lang läuft. Deswegen kann ich auch nicht kurz Anwendung starten, hier und da rumklicken und dann beenden. Ich muss die mit Live-Daten etliche Stunden / Tage laufen lassen damit das Phänomen überhaupt auftritt.

Ob da wirklich Objekte drin sind, die ich vergesse aufzuräumen ist zudem nur Vermutung. Es könnte auch tatsächlich 'nur' an Fragmentierung liegen. Es kann allerdings genausogut an einer anderen Stelle im Programm liegen, deren Verantwortliche das aber kategorisch ablehnen.

Die Idee ist nun, mit möglichst wenig Aufwand (und ohne Try & Error) herauszufinden, ob das an meinem Teil liegt oder nicht. Insbesondere, weil wir das eben hier nicht auf die schnelle reproduzieren können.

[alzaimar]

Zitat:

Zitat von Phoenix

Und ich befürchte fast, dass ich in so einem Fall einfach irgendwo vergesse, alte, nicht mehr benötigte Objekte aufzuräumen.

Dann schreib dir eine Scanroutine, die nach einem Datenwechsel (wenn der Baum also aufgeräumt wird) nachschaut, ob auch wirklich alle Objekte weg sind. Dazu kannst du auch meinen Trick mit den IDs und der Liste nehmen. Einfach mitloggen, was erzeugt wird und hinterher durchgehen, welche Objekte gemeinerweise nicht freigegeben wurden...

[Phoenix]

Zitat:

Zitat von alzaimar

Dann schreib dir eine Scanroutine, die nach einem Datenwechsel (wenn der Baum also aufgeräumt wird) nachschaut, ob auch wirklich alle Objekte weg sind.

Der Baum wird ja nicht aufgeräumt. Er wird nur umorganisiert.

Und diesen Code zu reviewen brauch wahrscheinlich länger, als es gedauert hat ihn zu schreiben. Und das war schon ne ganze Weile. Das allein aufgrund einer reinen Vermutung zu machen bekomme ich nicht bezahlt, und ich kann den Aufwand auch nicht vor dem Kunden vertreten.