Verständnisfrage: TJSONObject create/free/destroy?

[KodeZwerg]

Zitat:

Zitat von SearchBot (Beitrag 1509313)

Wie kann ich messen, ob ich innerhalb einer procedure ein Speicherleck habe (ich habe bisher nur den Taskmanager beobachtet, wie sich der Speicher meiner App verändert)?

Dafür liebe ich den Process Hacker bereites seit vielen vielen Jahren, da sehe ich detailiert Speichernutzung, Handles etc... Find ich ist ein Klasse Tool um sowas mal rasch zu checken.

[Uwe Raabe]

Delphi-Quellcode:

    try
      jsonArr:= TJSONArray.Create;
      jsonArr.owned:=false;
      jsonArr.Add(p1);
      jsonArr.Add(p2);

      json.AddPair('path', jsonArr);

Mit dem AddPair bekommt das json das jsonArr ja übergeben. Wegen Owned := False gibt es das in seinem Destroy zwar nicht frei, aber reagiert doch verschnupft, wenn es jemand außerhalb freigibt ohne ihm das vorher durch ein RemovePair mitzuteilen.

[himitsu]

Zitat:

Zitat von Uwe Raabe (Beitrag 1509318)

aber reagiert doch verschnupft, wenn es jemand außerhalb freigibt ohne ihm das vorher durch ein RemovePair mitzuteilen.

Ist aber auch klar, warum.

Es geht seine Child-Liste durch und will bei dem JsonArr nachsehn, was im .Owned drin steht, also ob es das freigeben soll, oder nicht.
Frage ist jetzt nur, warum Eba vergessen hat bei Freigabe von TJSONArray in dessen Owner sich aus der Liste auszutragen.

z.B. bei TObjektList steht das "Owned" im Owner und nicht in jedem Child ... Er guckt also nur in sich selbst nach, ob es freigeben soll, somit kann ihm dort egal sein, ob die Child-Objekte noch existieren, weil es nicht da drauf zugreifen muß.

[SearchBot]

Zitat:

Zitat von himitsu (Beitrag 1509314)

ReportMemoryLeaksOnShutdown := True;

Siehe FastMM Debug-Optionen

Oder eben sich ins Freigeben hängen ... dann siehst du was freigegeben wird (und was nicht) :angle:

Ich habe mir jetzt das FastMM vom Github geholt und eingebaut.
Und damit auch schon ein MemLeak behoben in einer Komponente (PageExtControl, die ich sehr gerne verwende (da wurde TTabColors im destroy nicht wieder freigegeben, aber das nur nebenbei)).

Mit FastMM habe ich jetzt aber ein ganz neues unerklärliches Problem :pale:

Delphi-Quellcode:

procedure OpenGrid(var Grid:TStringGrid;Filename:string;Separator:AnsiChar);
var sl:TSTringList;
begin
  try
    sl:=TStringList.Create;
    sl.LoadFromFile(Filename);
   //mache was damit
  finally
     sl.Free
  end;
end;

Bei dem sl.free hüpft FastMM dann in seine Funktion DebugFreeMem und kreiselt dort herum.
Es kehrt danach nicht mehr in meine Procedure zurück, in der ich OpenGrid aufgerufen habe... :pale:

Hat das FastMM da einen Bug (auch wenn das in der beiliegenden readme ausgeschlossen wird)?
Ich dachte FastMM soll helfen und keine neuen Bugs produzieren!?

[SearchBot]

Zitat:

Zitat von Uwe Raabe (Beitrag 1509318)

Mit dem AddPair bekommt das json das jsonArr ja übergeben. Wegen Owned := False gibt es das in seinem Destroy zwar nicht frei, aber reagiert doch verschnupft, wenn es jemand außerhalb freigibt ohne ihm das vorher durch ein RemovePair mitzuteilen.

Das TJSONgedöns hat mir irgendwie zuviel nicht nachvollziehbares Eigenleben.
Ich hab jetzt alle Freigaben und das Owned entfernt und gebe ganz zum Schluss nur das json.free

Jetzt schaue ich mir an, was FastMM dazu entdeckt, wie mir Himitsu empfohlen hat.

Und je, irgendwie ist das mit dem TJSONObject trotzdem nicht gut :roll: - ich habe die Funktion damit nur 1x aufgerufen und Auszug:

Code:

13 - 20 bytes: TJSONNumber x 2, TJSONObject x 2, TJSONString x 10, TJSONPair x 6, Unknown x 1

Offenbar gibt TJSON das nicht so frei, wie wir uns es erhofft haben.

[Uwe Raabe]

Zitat:

Zitat von SearchBot (Beitrag 1509385)

Offenbar gibt TJSON das nicht so frei, wie wir uns es erhofft haben.

Alternativ könnte es aber auch an deinem Code liegen :?

[TiGü]

Zitat:

Zitat von SearchBot (Beitrag 1509382)

Mit FastMM habe ich jetzt aber ein ganz neues unerklärliches Problem :pale:

Delphi-Quellcode:

procedure OpenGrid(var Grid:TStringGrid;Filename:string;Separator:AnsiChar);
var sl:TSTringList;
begin
  try
    sl:=TStringList.Create; // <---- Konstruktor-Aufruf IMMER vor dem try!
    sl.LoadFromFile(Filename);
   //mache was damit
  finally
     sl.Free
  end;
end;

Bei dem sl.free hüpft FastMM dann in seine Funktion DebugFreeMem und kreiselt dort herum.
Es kehrt danach nicht mehr in meine Procedure zurück, in der ich OpenGrid aufgerufen habe... :pale:

Hat das FastMM da einen Bug (auch wenn das in der beiliegenden readme ausgeschlossen wird)?
Ich dachte FastMM soll helfen und keine neuen Bugs produzieren!?

Siehe Kommentar oben im Zitat.

[SearchBot]

Zitat:

Delphi-Quellcode:

 try
    sl:=TStringList.Create; // <---- Konstruktor-Aufruf IMMER vor dem try!

Vielen Dank für den Hinweis. Hab das häufiger im Quelltext falsch gemacht und jetzt korrigiert.

Aber es ändert nichts am Verhalten vom FastMM -
Es wirft mir eine Exception - Zugriffverletzung bei Adresse... und wenn ich dort schaue, mitten im CPU-Fenster ist es in "@UStrAsg" :gruebel: Weiß nicht, was das ist... irgendwas mit UniCodeString in der Nähe - "Lesen von Adresse 8B2E2583".

Kommentiere ich die Unit FastMM aus, gibt es keinen Fehler.

[himitsu]

[edit]
im Stacktrace nachschauen, was vor dem UStrAsg war?

UStrAsg ist z.B. ein

Delphi-Quellcode:

StringVariable1 := StringVariable2;

[/edit]

Zitat:

Konstruktor-Aufruf IMMER vor dem try!

Im Prinzip stimmt die Aussage.

Erst nach "erfolgreichem" Create ist SL zugewiesen und Free kann auch wirklich was tun.
Alternativ kann man vor dem Try auch ein

Delphi-Quellcode:

SL:=nil;

einfügen, dann hat SL beim Free auch einen gültigen Wert, selbst wenn es im oder schon vorm Create knallt.

Und warum hört eigentlich nie jemand auf den Compiler, denn der sagt doch bestimmt, dass da was falsch ist. :roll:



Aber da es hier extrem unwahrscheinlich ist (außer das Programm war vorher schon im Arsch), dass hier das Create knallen würde, müßte Create bereits vorbei sein und es hatte danach geknallt.
Wenn es da also im Free abraucht, dann liegt es nicht am "ungültigen" SL, sonder würde eher z.B. für einen Bufferoverrun oder zerschossenen Stack sprechen ... so oder so ist da eh alles im A und alles Weitere wäre sinnlos.




Auch wenn es möglich wäre, ist es schon etwas unwahrscheinlich, dass es "wegen" FastMM knallt.
Eher war vorher schon ein Fehler da, der jetzt nur noch besser auffällt.

[SearchBot]

Ja, da hast du recht, mein Code ist schon ein wenig hingeschmiert :oops:

Ich habe es schon fast vergessen gehabt, daß da noch was war mit... - wenn man ältere Quelltexte verwendet und Delphi zwischenzeitlich "String" als UnicodeString versteht, ich aber weiterhin in AnsiString denke.

Also habe ich im alten Code nun alles, was Char und String hieß, spezifiziert (char -> AnsiChar; String -> AnsiString; leider geht es bei AnsiString jetzt nicht mehr mit .toInteger -> strtoint() ...

Und ich habe bei dem, was ich nach dem Laden der SL getan habe, auch noch eine Sonderbehandlung eingebaut .. und jetzt knallt es dort nicht mehr. :thumb:

Kann ich Delphi dazu bringen, das String als AnsiString zu verstehen statt alles mit dem blöden UnicodeString zu machen?

Viele Leaks werden auch in den Indy-Typen gemeldet. Und haufenweise bei UnicodeString.
Ich habe neben den system.TJSON auch eine Unit TdJSON ( https://github.com/thomaserlang/delp...ster/djson.pas ), in der auch viele Leaks passieren, womöglich insgesamt das Themenproblem verursachen.. :roll: