Abgeleitet von TObject -> Destroy -> Inherited -> Ung. Zeig.

[Robert_G]

Zitat von Spider:

sorry, wusste doch, ich hab was vergessen. TUpdate hat keinen destructor.

Irgendwo musst du aber auf einen freigegebenen Zeiger zugreifen. In dem gezeigten Code dürfte nichts zu einer AV führen...

Nur mal so am Rande...

Zitat von Spider:

Erzeugen tu ich so:

Delphi-Quellcode:

constructor TLiveUpdate.Create;
begin
  FFiles := TObjectList.Create;
  Updates := TObjectList.Create;
...

Zitat von Spider:

  FreeAndNil(Updates); // steppe per F7 hier her

Merkst du was? Wenn nicht: Cursor auf TObjectList -> [F1] -> Konstruktor anschauen -> dort oder unter "see also" dürfte dir erklärt werden warum du ein MemLeak hast.

Wobei ich trotz des MemLeak keinen Grund für einen Zugriff auf ein nil-Referenz sehe.
Wenn du FreeAndNil wegnimmst und ein normales Free aufrufst... Ändert sich jetzt die Adresse der AV?
Wenn ja greifst du noch auf die Felder zu.

[Muetze1]

Moin!

Zitat von Robert_G:

Merkst du was? Wenn nicht: Cursor auf TObjectList -> [F1] -> Konstruktor anschauen -> dort oder unter "see also" dürfte dir erklärt werden warum du ein MemLeak hast.

Warum? Woher? TObjectList's OwnsObject ist standardmässig auf True, daher kapiere ich nicht woher der MemLeak kommen sollte...

MfG
Muetze1

[Robert_G]

Zitat von Muetze1:

Moin!

Zitat von Robert_G:

Merkst du was? Wenn nicht: Cursor auf TObjectList -> [F1] -> Konstruktor anschauen -> dort oder unter "see also" dürfte dir erklärt werden warum du ein MemLeak hast.

Warum? Woher? TObjectList's OwnsObject ist standardmässig auf True, daher kapiere ich nicht woher der MemLeak kommen sollte...

*Delphi installier* Ich hatte es jedenfalls anders in Erinnerung...
Edit: Hast recht...

Delphi-Quellcode:

constructor TObjectList.Create;
begin
  inherited Create;
  FOwnsObjects := True;
end;

[Die Muhkuh]

Hi,

ich hab nun herausgefunden, dass es an FreeAndNil(Updates) liegt. Der Fehler kommt nur, wenn ich der Liste was hinzufüge. Wenn ich nun Updates := TObjectList.Create(False) mache, anstatt Updates := TObectList.Create dann bekomme ich die Meldung nicht.

[Robert_G]

Jetzt kommt der Punkt, an dem hier niemand mehr etwas schreiben wird.
Und zwar weil wir nicht erraten können, ob du noch nach dem Destroy eines Updates darauf zugreifst.

Auch wenn ich den Default wert von OwnsItems falsch in Erinnerung hatte, alleine das Hin & Her sollte dir klar gemacht haben, was die Eigenschaft bewirkt.
Und deshalb verstehe ich einfach nicht, wie du schon wieder praktisch null (nada, nüscht, niente,...) Informationen lieferst...

p.s.: Nur für den Fall dass du zu faul zum Lesen der OH warst: TObjectList.Create(False) bewirkt, dass die Elemente NICHT freigegeben werden.
*sich langsam verarscht vorkommt*

[Die Muhkuh]

Zitat:

Und zwar weil wir nicht erraten können, ob du noch nach dem Destroy eines Updates darauf zugreifst.

Hi,

ich hab den Fehler jetzt endgültig gefunden.

Es lag nicht am destruktor, sondern daran, wie ich die Items hinzugefügt habe:

Delphi-Quellcode:

procedure TLiveUpdate.SearchUpdates;
  function MD5File(const FileName: String): String;
  begin
    with THash_MD5.Create(nil) do
    begin
      Result := CalcFile(FileName, nil, fmtHex);
    end;
  end;
var
  SL: TStringList;
  S: String;
  I: Integer;
  U, U2: TUpdate;
begin
  FFiles.Clear;
  Updates.Clear;

  Searching := true;

  Download(URLFileList + FileListName, ExePath + FileListName);

  SL := TStringList.Create;

  try
    try
      SL.LoadFromFile(ExePath + FileListName);

      // Datei parsen
      for I := 0 to SL.Count - 1 do
      begin
        S := SL.Strings[I];

        U := TUpdate.Create;

        // Source
        U.Source := Copy(S, 0, Pos(';', S) - 1);
        Delete(S, 1, Pos(';', S));

        // Hash
        U.MD5 := Copy(S, 0, Pos(';', S) - 1);
        Delete(S, 1, Pos(';', S));

        // Dest
        U.Dest := Copy(S, 0, Pos(';', S) - 1);
        Delete(S, 1, Pos(';', S));

        // Size
        U.Size := StrToInt(Trim(S));

        FFiles.Add(U);
      end;

      // Updates zusammenbauen
      for I := 0 to FFiles.Count - 1 do
      begin
        try
          if (not (FileExists(ExePath + TUpdate(FFiles.Items[I]).Dest))) then
          begin
            // Das ist das aktuelle, das funktioniert!
            U2 := TUpdate.Create;
            with TUpdate(FFiles.Items[I]) do
            begin
              U2.Size := Size;
              U2.Dest := Dest;
              U2.Source := Source;
              U2.MD5 := Md5;
            end;
            Updates.Add(U2);
          end
          else
          begin
            if MD5File(ExePath + TUpdate(FFiles.Items[I]).Dest) <>
              TUpdate(FFiles.Items[I]).MD5 then
            begin
              // Das war das alte, dass hat nicht funktioniert
              U2 := TUpdate(FFiles.Items[I]);
              Updates.Add(U2);
            end;
          end;
        except
        end;
      end;
    finally
      FreeAndNil(SL);
    end;
  except
    on E: Exception do
      Error('Während dem Parsen ist ein Fehler aufgetreten:' + #10#10 + '%s',
        [E.Message]);
  end;

  UpdateCount := Updates.Count;
  Searching := false;
end;

Ich schätze mal das war so:

Ich erzeuge soviele TUpdates wie Zeilen in einer StringList und füge diese TUpdates in FFiles ein. Danach wird überprüft, ob die Hashsumme der localen Datei von der Hashsumme der aktuellen Datei unterscheidet, wenn ja, dann wird U2 das aktuelle TUpdate hinzugewiesen. Als ich nun FFiles freigebe, werden ja die ganzen Tupdates mit freigegeben, aber die TUpdates in Updates ( ) sind immer noch auf die Updates referenziert, die in FFiles sind, demnach kommt eine Fehlermeldung, weil die TUpdates gar nicht mehr vorhanden sind.

Hoffe das versteht einer^^.

Ausserdem brauchst du dir, Robert, nicht verarscht vorkommen, denn ich bin ma wieder auffem Schlauch gestanden