Freigeben -> AV; Bearbeiten -> Nichts weiter

[angos]

Hi,

ich hatte schon 2, 3 Male ein ähnliches Phänomen. Selbst bei noch eindeutigeren "Nicht-Fehlern" im Code

eine Funktion hat eine Exception geworfen. Zum prüfen habe ich folgende Änderungen im Code vorgenommen:

Delphi-Quellcode:

function XYZ;
var  
  s: string; // geändert
  i: Integer;
begin
  [...]
  s := IntToStr(i); // geändert
  [...]
  ShowMessage(s); // geändert
  [...]
end;

danach kam die Exception nicht mehr.
Auskommentieren dieser Zeilen hat die Exception zurückgebracht. Bei mir im Betrieb waren alle Entwickler ratlos.
Also habe ich mal alle *.dcu und ProjektName.* außer der Projektname.dpr.

Danach Projekt neu erzeugt und alles hat wieder einwandfrei funktioniert.

Vielleicht verschluckt sich Delphi bei dir auch an irgend wo einer Kleinigkeit.


Gruß

Ansgar

[jaenicke]

Das sind meistens alles Symptome für Speicherprobleme. Leider tritt, wenn man den falschen Speicher überschreibt z.B., der Fehler oft am anderen Ende des Projekts auf und ist dort unerklärlich.
Und leider ist so etwas nicht unbedingt reproduzierbar.

Und leider können ganz andere Änderungen, die eigentlich nichts damit zu tun haben das Problem verdecken. Sei es eine zusätzliche Variable, ein zusätzlicher Befehl, der eigentlich gar nix macht, oder sowas.
Eine nicht computerbezogene Erklärung habe ich dazu einmal hier geschrieben:
http://www.delphi-forum.de/viewtopic...=527022#527022

Deshalb sind die Hinweise von Delphi auf Speicherlecks sehr Ernst zu nehmen. Irgendetwas stimmt da definitiv nicht. Ich habe nur gerade bis eben an einem eigenen Projekt gearbeitet, so dass ich mich da nicht drum kümmern konnte. Ich schau es mir gleich noch einmal genauer an.

[xZise]

Zitat von jaenicke:

Das sind meistens alles Symptome für Speicherprobleme. Leider tritt, wenn man den falschen Speicher überschreibt z.B., der Fehler oft am anderen Ende des Projekts auf und ist dort unerklärlich.
Und leider ist so etwas nicht unbedingt reproduzierbar.

Genau das ist das Problem, und genau deshalb glaube ich, dass ich irgendwo in den Listen unsauber gearbeitet habe.

Zitat von jaenicke:

Deshalb sind die Hinweise von Delphi auf Speicherlecks sehr Ernst zu nehmen. Irgendetwas stimmt da definitiv nicht. Ich habe nur gerade bis eben an einem eigenen Projekt gearbeitet, so dass ich mich da nicht drum kümmern konnte. Ich schau es mir gleich noch einmal genauer an.

Genau deshalb verwenden wir im eigentlich Projekt die alten Varianten, aber die neue ist halt (meiner Meinung nach) besser
Da der Fehler auftritt, wenn ich eine von beiden neuen Listen verwende, glaube ich, liegt es an der TMainList.

MfG
xZise

[jaenicke]

Was mir auffällt:

Delphi-Quellcode:

procedure TMainList.Clear;
begin
  FCount := 0;
  case FReserveManagment of
    rmExact, rmProgressive: begin
      FReservedLength := 0;
    end;
  end;
end;

und

destructor TMainList.Destroy;
begin
  inherited;
end;

Müsste nicht in beiden Fällen Speicher freigegeben werden?

[xZise]

Also ich bin mir da nicht so sicher. Bei Clear sollte ich das Array wirklich einmal resizen. Aber ansonsten ist das ja ein dynamisches array von TVarRec, welches ja an sich automatisch "freigegeben" wird?

MfG
xZise

[jaenicke]

Naja, was heißt automatisch freigegeben, ich sehe kein SetLength(..., 0), und das müsste da eigentlich irgendwo stehen. Denn sonst gibts doch erstmal noch eine Referenz auf die Objekte und der Referenzzähler wird nach dem Freigeben der Liste nicht 0. Denn deren Freigabe zerstört zwar die Referenzen, aber das passiert ja nicht explizit.

Ich hab gerade mal in die Implementierung von TList geschaut, daran solltest du dich vielleicht orientieren:

Delphi-Quellcode:

destructor TList.Destroy;
begin
  Clear;
end;

procedure TList.Clear;
begin
  SetCount(0);
  SetCapacity(0);
end;

Das heißt da wird durchaus explizit gelöscht.

Sicher bin ich mir über die Interna der Referenzzählung aber aus dem Kopf auch nicht, da schaue ich immer in den generierten Assemblercode, wenn ich nicht sicher bin.

[xZise]

Okay habe ich eigentlich auch:

Delphi-Quellcode:

destructor TMainList.Destroy;
begin
  Clear;
  ResizeArray(0);
  inherited;
end;

procedure TMainList.Clear;
begin
  FCount := 0;
  case FReserveManagment of
    rmExact, rmProgressive: begin
      FReservedLength := 0;
    end;
  end;
  ResizeArray(FReservedLength);
end;

Aber es kommt weiterhin der Fehler und die Speicherlecks sind weiterhin vorhanden.

MfG
xZise

[jaenicke]

Um genauer zu schauen wo die Speicherlecks liegen solltest du dir einmal FastMM anschauen und die Überprüfung aktivieren.

Und dann gibts da noch madExcept oder EurekaLog, die zum Debuggen sehr gut sind.

[dataspider]

Hi,

mir ist beim Lesen auch noch etwas aufgefallen:

Delphi-Quellcode:

procedure TIntegerListList.Delete(const AIndex: Integer);
begin
  // next condition can not be True - or statt and
  // genau so in: TIntegerListList.GetIntegerLists
  if (AIndex < 0) and (AIndex >= Count) then
    raise EIntegerListListError.CreateFmt(SListIndexError, [AIndex]);
  FIntegerLists.Delete(AIndex);
  FHeadInteger.Delete(AIndex);
  Dec(FCount);
end;

Delphi-Quellcode:

procedure TZeilenListe.Delete(AIndexes: TIntegerList);
var
  i: Integer;
begin
  for i := 0 to AIndexes.Count - 1 do
    Delete(AIndexes[i]);
end;

Kannst du garantieren, dass AIndexes absteigend sortiert ist? Sonst löscht du die falschen oder bist plötzlich ausserhalb des Bereiches.

Cu, Frank

[xZise]

Ah okay.

Normalerweise denke ich immer an die Rückwärtige Schleife. Ich probiere es gleich mal aus!

Aber du meinst die falsche TIntegerListList ^^, aber wenn ich die Schleife in UZeilen umdrehe hat das keine Auswirkung.

Und wie sieht es mit FastMM aus? Also ich habe mir jetzt FastMM4 gedownloadet, aber wie erhalte ich genauere Angaben?

MfG
xZise