AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Memoryleak oder doch nicht?

Ein Thema von EWeiss · begonnen am 29. Mär 2018 · letzter Beitrag vom 30. Mär 2018
Antwort Antwort
Seite 1 von 2  1 2   
EWeiss
(Gast)

n/a Beiträge
 
#1

Memoryleak oder doch nicht?

  Alt 29. Mär 2018, 07:43
Die Meldung.
Zitat:
--------------------------------------------------------------------------------------------------------------------------------------
|Methods |Details|Stack |Address |Module |Offset |Unit |Class |Procedure/Method |Line |
--------------------------------------------------------------------------------------------------------------------------------------
|+Leak #1: Type=UnicodeString: Ref count - 1, Content: "'WARNING: DO NOT CHANGE THE ORDER OF THE PROPERTIES!"; Total size=118; Count=1|
|------------------------------------------------------------------------------------------------------------------------------------|
|00000002|03 |00000000|005E8586|SK_Aero.dll |00008586|System | |InternalUStrFromPCharLen | |
|00000002|04 |00000000|0082C55B|SK_Aero.dll |0024C55B|uSkinConfig|TSkinConfig|FBuffin |976[12] |
|00000002|04 |00000000|0082ABEF|SK_Aero.dll |0024ABEF|uSkinConfig|TSkinConfig|GetConfiguration |308[5] |
|00000002|04 |00000000|008234C4|SK_Aero.dll |002434C4|uSkin |TSkinEngine|InitSkin |644[25] |
|00000002|04 |00000000|00833E1B|SK_Aero.dll |00253E1B|uMaster | |SKAERO_InitSkin |806[4] |
|00000002|03 |00000000|75213366|kernel32.dll|00013366|kernel32 | |BaseThreadInitThunk | |
|00000002|03 |00000000|77019900|ntdll.dll |00039900|ntdll | | (possible RtlInitializeExceptionChain+97)| |
|00000002|03 |00000000|770198CE|ntdll.dll |000398CE|ntdll | | (possible RtlInitializeExceptionChain+47)| |
|------------------------------------------------------------------------------------------------------------------------------------|
Wie soll ich das jetzt interpretieren?
Wo oder was ist der Leak UnicodeString?

Aber wie soll dieser entstehen wenn ich doch die Classe beim beenden freigebe?
Delphi-Quellcode:
destructor TSkinEngine.Destroy;
begin

  if Assigned(SkinConfig) then
    SkinConfig.free;

  SkinLoaded := False;
  SkinEngine := nil;

  inherited;
end;
Noch mehr kann ich nicht tun.
Und hier wird das File geschlossen.
Delphi-Quellcode:
procedure TSkinConfig.FBuffin(FileName: string);
var
  sBuffer: string;

begin

  if not FExist(FileName) then
    Exit;

  Assignfile(ParseFile, FileName);
  reset(ParseFile);

  try
    try
      while not eof(ParseFile) do
      begin
        ReadLN(ParseFile, sBuffer);
        AppendToLinkedList(nReading, sBuffer);
        inc(nReading);
      end;
    except
      raise Exception.Create(SysErrorMessage(GetLastError));
    end;
  finally
    nReading := 0;
    sBuffer := '';
    CloseFile(ParseFile);
  end;
end;
noch bevor die Anwendung beendet wird.
Was will er mir jetzt mit dem FBuffin sagen?

EDIT:
Dieser string wird aus der Textdatei geladen
'WARNING: bla, bla!"

Nun die Datei wird ordnungsgemäß geschlossen und die Classe freigegeben verstehe wer will.
Der String existiert doch dann gar nicht mehr.

gruss

Geändert von EWeiss (29. Mär 2018 um 08:32 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.008 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#2

AW: Memoryleak oder doch nicht?

  Alt 29. Mär 2018, 10:38
Also gemäß des Callstacks geht es um den Inhalt von sBuffer. Innerhalb der FBuffin Methode läuft da alles gut, also bleibt nur die Frage: Was wird in AppendToLinkedList(nReading, sBuffer) damit gemacht?

Meine Vermutung: dort wird irgendwie der RefCount des strings aus dem Gleichgewicht gebracht.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight

Geändert von Stevie (29. Mär 2018 um 10:41 Uhr)
  Mit Zitat antworten Zitat
EWeiss
(Gast)

n/a Beiträge
 
#3

AW: Memoryleak oder doch nicht?

  Alt 29. Mär 2018, 10:41
Also gemäß des Callstacks geht es um den Inhalt von sBuffer. Innerhalb der FBuffin Methode läuft da alles gut, also bleibt nur die Frage, was wird in AppendToLinkedList(nReading, sBuffer); damit gemacht.

Meine Vermutung: dort wird irgendwie der RefCount des strings aus dem Gleichgewicht gebracht.
Bitte das hier..

Delphi-Quellcode:
procedure TSkinConfig.AppendToLinkedList(nReading: Integer; sBuffer: string);
begin

  New(FPBuffer);

  if nReading = 0 then
  Begin
    New(FToPBuffer);
    LineStart := FToPBuffer;
    LineStart^.Nr := 0;
  end;

  FPBuffer^.Nr := nReading;
  FPBuffer^.Str := sBuffer;
  LineStart^.Max := nReading;
  FToPBuffer^.Ptr := FPBuffer;
  FToPBuffer := FPBuffer;

end;
Es werden nur die Zuweisungen aktualisiert.

EDIT:
Delphi-Quellcode:
  PParseFile = ^TParseFile;
  TParseFile = record
    Nr :Integer;
    Str : string;
    Ptr : PParseFile;
    Max : Integer;
  end;
Delphi-Quellcode:
    LineStart : PParseFile;
    FPBuffer : PParseFile;
    FToPBuffer : PParseFile;
gruss

Geändert von EWeiss (29. Mär 2018 um 10:48 Uhr)
  Mit Zitat antworten Zitat
Whookie

Registriert seit: 3. Mai 2006
Ort: Graz
441 Beiträge
 
Delphi 10.3 Rio
 
#4

AW: Memoryleak oder doch nicht?

  Alt 29. Mär 2018, 10:53
Dann liegt wohl da der Hund begraben:


  FPBuffer^.Str := sBuffer;
Whookie

Software isn't released ... it is allowed to escape!
  Mit Zitat antworten Zitat
EWeiss
(Gast)

n/a Beiträge
 
#5

AW: Memoryleak oder doch nicht?

  Alt 29. Mär 2018, 11:00
Dann liegt wohl da der Hund begraben:


  FPBuffer^.Str := sBuffer;
Warum ?
Beides sind string.

gruss

Geändert von EWeiss (29. Mär 2018 um 11:04 Uhr)
  Mit Zitat antworten Zitat
Fritzew

Registriert seit: 18. Nov 2015
Ort: Kehl
678 Beiträge
 
Delphi 11 Alexandria
 
#6

AW: Memoryleak oder doch nicht?

  Alt 29. Mär 2018, 11:02
Wann und vor allem wie gibst Du
FPBuffer^.Str := sBuffer; wieder frei?
Fritz Westermann
  Mit Zitat antworten Zitat
EWeiss
(Gast)

n/a Beiträge
 
#7

AW: Memoryleak oder doch nicht?

  Alt 29. Mär 2018, 11:06
Wann und vor allem wie gibst Du
FPBuffer^.Str := sBuffer; wieder frei?
Nach dem Parsen des TextFile.

Delphi-Quellcode:
  // Resourcen Freigeben
  Dispose(FPBuffer);
  FPBuffer := nil;
  Dispose(LineStart);
  LineStart := nil;
  Result := True;
EDIT:
Mit new erstellt und Dispose freigegeben.

gruss

Geändert von EWeiss (29. Mär 2018 um 11:08 Uhr)
  Mit Zitat antworten Zitat
Fritzew

Registriert seit: 18. Nov 2015
Ort: Kehl
678 Beiträge
 
Delphi 11 Alexandria
 
#8

AW: Memoryleak oder doch nicht?

  Alt 29. Mär 2018, 11:11
Da liegt der Hund begraben.....
Der String wird nich freigegeben.

mach einfach
Delphi-Quellcode:
finalize(FPbuffer^);
//oder
FPBuffer^.Str := nil;

Dispose(FPBuffer);
FPBuffer := nil;
Wenn Du nur den Speicher freigibst werden die Strings nicht gelöscht.

Aus der Hilfe zu finalize

Zitat:
Die Variable enthält lange Strings, Varianten und Interfaces, die nicht alle leer sind bzw. den Wert Unassigned haben.

Finalize setzt einfach alle langen Strings auf einen leeren Wert und alle Varianten und Interfaces auf Unassigned und sorgt somit für die ordnungsgemäße Freigabe des betreffenden Speichers.
Fritz Westermann
  Mit Zitat antworten Zitat
EWeiss
(Gast)

n/a Beiträge
 
#9

AW: Memoryleak oder doch nicht?

  Alt 29. Mär 2018, 11:15
Dann werde ich es mal so bearbeiten wie von dir vorgeschlagen.. Danke.

Hmmm dachte eigentlich ein Dispose würde reichen.
Ok wieder was gelernt.

gruss
  Mit Zitat antworten Zitat
EWeiss
(Gast)

n/a Beiträge
 
#10

AW: Memoryleak oder doch nicht?

  Alt 29. Mär 2018, 11:20
Jetzt habe ich nur noch eins.
Dann ist alles bereinigt.

Zitat:
--------------------------------------------------------------------------------------------------------------------------------------
|Methods |Details|Stack |Address |Module |Offset |Unit |Class |Procedure/Method |Line |
--------------------------------------------------------------------------------------------------------------------------------------
|+Leak #1: Type=Data at $05C5FF90; Total size=480; Count=30 |
|------------------------------------------------------------------------------------------------------------------------------------|
|00000002|03 |00000000|009C9865|SK_Aero.dll |00009865|System | |_New | |
|00000002|04 |00000000|00C0DECF|SK_Aero.dll |0024DECF|uSkinConfig|TSkinConfig|FBuffin |989[13] |
|00000002|04 |00000000|00C0C4EE|SK_Aero.dll |0024C4EE|uSkinConfig|TSkinConfig|GetConfiguration |305[5] |
|00000002|04 |00000000|00C11ADF|SK_Aero.dll |00251ADF|uSkin |TSkinEngine|InitSkin |648[28] |
|00000002|04 |00000000|00C08DCB|SK_Aero.dll |00248DCB|uMaster | |SKAERO_InitSkin |804[2] |
|00000002|03 |00000000|75213366|kernel32.dll|00013366|kernel32 | |BaseThreadInitThunk | |
|00000002|03 |00000000|77019900|ntdll.dll |00039900|ntdll | | (possible RtlInitializeExceptionChain+97)| |
|00000002|03 |00000000|770198CE|ntdll.dll |000398CE|ntdll | | (possible RtlInitializeExceptionChain+47)| |
--------------------------------------------------------------------------------------------------------------------------------------
Deine Änderung hat geholfen Danke nochmal.

Delphi-Quellcode:
  // Resourcen Freigeben
  finalize(FPbuffer^);
  Dispose(FPBuffer);
  FPBuffer := nil;
  finalize(LineStart^);
  Dispose(LineStart);
  LineStart := nil;
  Result := True;
gruss
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2   

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 20:59 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz