Verständnisfrage: TJSONObject create/free/destroy?

[SearchBot]

Ich habe irgendwie eine Wissenslücke oder denke falsch.
Leider hilft auch nicht "RTFM" :wall:
Bisher nahm ich an, daß Objekte, die ich in einer Methode create auch brav wieder freigebe (zB TStringList).

Bei Beispielen mit TJSONObject scheint aber manches anders zu laufen - was mich sehr verwirrt und der Code bei Ausführung entweder knallt oder Windows mein Programm freundlicherweise ohne jeden Hinweis einfach beendet, nachdem es zuvor Fehlermeldungen an überraschenden Stellen ausgibt, die bislang sehr gut funktioniert haben (also MemoryLeak bei Verwendung von TJSONObject?).. :pale:

Ich habe also ein Programm anhand von Beispielen zusammengebaut, das lief bislang eigentlich gut, dann fiel mir das Leak auf und ich begann damit, alles mit create geschaffene auch wieder mit free zu entfernen.

:?: Sollte ich besser destroy anstelle von free verwenden?
Die Hilfe sagt "Mit Destroy geben Sie die TJSONObject-Instanz frei." - Aha, wozu gibt es dann auch Free? Es knallt aber in beiden Fällen.
Leider strotzt die Hilfe nur so mit nicht vorhandenen Anwendungsbeispielen.
Und die Beispiele im Internet verzichten häufig auf die Freigabe oder realisieren sie mit .free - und tatsächlich, an manchen Stellen in meinem Code funktioniert die Freigabe von TJSONObject auch mit .free ohne zum knallen :gruebel:

Nundenn, ich baue einen Request zusammen und sende ihn dann an ein Gerät - hier nur der Code als Beispiel bzw. wie es nacheinander kommt:

Delphi-Quellcode:

var json, p1, p2: TJSONObject;
    jsonArr: TJSONArray;
    JsonToSend : TStream;

... und im Laufe des Codes (und es steht noch mehr dazwischen, was prop,cv füllt)

Delphi-Quellcode:

try
  json := TJSONObject.Create;
  json.AddPair(prop, TJSONString.create(cv));

 try
  p1 := TJSONObject.Create;
  p2 := TJSONObject.Create;

  p1.AddPair(prop, TJSONBool.Create(cv='true'))
  p2.AddPair(prop, TJSONNumber.Create(cv));

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

   json.AddPair('path', jsonArr);
  finally
   jsonArr.Free;
  end;

 finally
   //jetzt brauche ich diese Objekte nicht mehr also..
   p1.Free; // hier knallt es schon "Ungültige Zeigeroperation", ebenfalls mit .Destroy
   p2.Free;
 end;

 try
  JsonToSend := TStringStream.Create(json.ToString);
  JsonToSend.Position := 0;
  //...
 finally
  JsonToSend.Free; //kein Problem
 end;

finally
 json.free; // sonst knallt es auch hier
end;

Ich hatte meinen Code auch schon so, daß ich

Delphi-Quellcode:

p1 := json;

schrieb, in der Absicht, was in json steht, Fall-bedingt zu ergänzen. Das hat auch funktioniert, aber später hab ich es mir dann nicht mehr selbst erklären können, warum es funktioniert, denn ich fragte mich "was weise ich damit eigentlich zu?"...
RTFM: da steht was von Clone für eine Kopie. Aber nicht, wie ich die Zuweisung beispielsweise schreiben soll.

Delphi-Quellcode:

p1:=json.clone;

funktioniert nicht (wo kann ich den TJSONAncestor denn zuweisen??).

Ist p1 dann eine unabhängige Kopie? Also, wenn ich p1 etwas zuweise (AddPair), verändert das nichts in json?
Oder ist p1 ein Pointer auf die gleiche Adresse wie json? Wenn ich dann also p1 etwas zuweise (Addpair), steht es automatisch auch im json so drin, als hätte ich statt p1 auch gleich json schreiben können?

Prüfen kann ich die Zuweisungen, die aber funktionieren, nicht, denn wenn ich mit F7/F8 durch die IDE steppe und auf die Variablen zeige, um den Wert zu sehen, steht da nur (0,0,0,0,0, ... $ad, ... ), was für mein Verständnis des Objekts wahnsinnig hilfreich ist :(

Also, viel Geschichte, aber zusammengefasst, was ich wissen möchte:
1) Was muss ich also wie freigeben in diesem Fall? Spielt die Reihenfolge eine Rolle?
1a) Wenn ich

Delphi-Quellcode:

p1.AddPair(prop, TJSONBool.Create(cv='true'));

schreibe, muss ich dann nicht auch noch TJSONBool.destroy machen (vielleicht gibt es hier ein Leak?), oder ist das nur eine Wertumwandlung?

2) Was weise ich damit eigentlich zu: p1:=json ?
2a) Wie muss die Zuweisung aussehen, wenn ich das Objekt mit den bisher gesammelten Daten kopieren will?
(einen String kann ich auf diese Weise kopieren und getrennt vom Original weiterarbeiten, aber wie mache ich das beim TJSONObject?)

3) Wenn ich also json.destroy schreibe und es ohne crash ausgeführt wird, warum sehe ich danach während des Debuggens in den "lokalen Variablen" das Objekt weiterhin mit allen Werten, als ob nichts geschehen wäre? Ich hätte erwartet, daß das Objekt dann nur noch () wäre!? :gruebel:

[himitsu]

Zitat:

Delphi-Quellcode:

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

   json.AddPair('path', jsonArr);
  finally
   jsonArr.Free; <<<<
  end;
 finally
   //jetzt brauche ich diese Objekte nicht mehr also..
   p1.Free; // hier knallt es schon "Ungültige Zeigeroperation", ebenfalls mit .Destroy
   p2.Free;
 end;

Beim Add übernimmt das JSONArray die Kontrolle, also Dieses gibt beim ersten Free auch P1 und P2 mit frei.

Zitat:

Sollte ich besser destroy anstelle von free verwenden?

Nein.

Destroy ruft man im Allgemeinen niemals direkt auf.

Und wenn schon Free knallt, dann kann Destroy nur noch mehr knallen, weil das if Assigned(Self) im Free fehlt
und es dann nicht nur bei "ungültigen" Zeigern knallt, sondern auch noch bei nil.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1509293)

Beim Add übernimmt das JSONArray die Kontrolle, also Dieses gibt beim ersten Free auch P1 und P2 auf.

Das ist ähnlich wie bei TObjectList<T> oder TStringList mit OwnsObject = True. Auch in diesen beiden Fällen übernimmt die Klasse das Wegräumen der Objekte.

[SearchBot]

Dankeschön :thumb:

Aber warum schreibt dann die blöde Hilfe so widersprüchliches Zeugs??
Bei TJSONObject.create heißt es, mit .Destroy sei es aufzuräumen. Zudem ist .Free im Hilfe-Index garnicht aufgelistet.
Bei TJSONObject.AddPair hat ein Beispiel, das das JSON-Objekt mit .Free aufräumt.
:wiejetzt:

Wäre ergänzend FreeAndNil sinnvoll?

Und wie kann ich das ahnen, daß das TJSONArray beim Free auch meine Objekte p1 und p2 mit in den Tod reißt? :pale:
Was kann ich tun, wenn ich die jetzt in einer Schleife habe und weiterverwenden möchte?

[Uwe Raabe]

Das ist in der Doku aber ganz gut beschrieben: Framework der JSON-Objekte

Zitat:

Lebenszyklus

In JSON ist das übergeordnete Objekt Eigentümer aller Werte, die es enthält, außer deren Eigenschaft Owned ist auf False gesetzt. In diesem Fall werden bei der Freigabe eines JSON-Objekts alle Member übersprungen, deren Flag auf False gesetzt ist. Dadurch wird das Zusammenfügen verschiedener Objekte zu größeren Objekten unter Beibehaltung der Eigentümerschaft möglich. Per Vorgabe ist die Eigenschaft True, das bedeutet, dass alle enthaltenen Instanzen Eigentum des übergeordneten Objekts sind.

[BerndS]

TJsonObject hat das Property Owned (TJSONAncestor).
Wenn du also

Delphi-Quellcode:

P1.Owned := False

setzt, sollte nichts freigegeben werden.

[SearchBot]

Aah, deshalb muss ich auch diese inline generierten Dinge nicht extra freigeben (zb das TJSONBool-Objekt in

Delphi-Quellcode:

json.AddPair(prop, TJSONBool.Create(cv='true'));

). Das ist praktisch.

Und wenn ich also Owned=false setze, gebe ich es (wie für mich normal und nachvollziehbar) am Ende erst frei.
[getestet] Schön, es knallt nicht mehr. :thumb:

Als Folge von Owned=false löst jetzt aber die Wertübergabe requestString:=json.ToString eine Zugriffsverletzung aus. Wieso? :pale:
Zerstört die Freigabe von P1 und P2 jetzt das plötzlich übergeordnete Objekt json (das ich auch Owned=false gesetzt habe)?

[himitsu]

Du kannst natürlich auch mit DebugDCUs kompilieren und dann einen Haltepunkt in TJSONObject.Destroy setzen und verfolgen wo/wann deine Objekte verschwinden und deine Variablen somit ungültig sind.

Teilweise könnte man auch mit [weak] arbeiten und seine Variable automatisch auf NIL setzen lassen, was aber nur bei aktivem ARC funktioniert (also leider nicht in Win32/Win64).

Delphi-Quellcode:

var
  [weak] J: TJSONObject;

oder z.B. sich anders ins Destroy reinhängen.

Delphi-Quellcode:

uses System.JSON, System.RTTI;

procedure TForm21.FormCreate(Sender: TObject);
var
  J: TJSONObject;
  VMI: TVirtualMethodInterceptor;
begin
  J := TJSONObject.Create;

  VMI := TVirtualMethodInterceptor.Create({TJSONObject} J.ClassType);
  VMI.Proxify(J);
  VMI.OnBefore := procedure(Instance: TObject; Method: TRttiMethod; const Args: TArray<TValue>; out DoInvoke: Boolean; out Result: TValue)
    begin
      if Method.Name = 'BeforeDestruction' then  // eigentlich hötte ich "Destroy" genommen, aber will nicht ... erst BeforeDestruction und dann nur noch FreeInstance (aber eigentlich hätte es gehen müssen)
        Beep;  << hier drauf einen Debugger-Haltepunkt
        // oder ShowMessage(Instance.ClassName);
        // oder ShowMessage(Instance.ClassName + ' ' + (Instance as TJSONAncestor).ToString);  // Achtung, .ToString landet natürlich ebenfalls in VMI.OnBefore

      //DoInvoke := True;  ist zwar OUT, aber eigentlich ist es VAR und bereits mit True initialisiert, also somit nicht unbedingt nötig
    end;

  //...

  J.Free;  // selber oder z.B. irgendwo via Owned innerhalb eines anderen Objekts
end;

[SearchBot]

Zitat:

Zitat von SearchBot (Beitrag 1509309)

Als Folge von Owned=false löst jetzt aber die Wertübergabe requestString:=json.ToString eine Zugriffsverletzung aus. Wieso? :pale:

Hab das TJSONArray nicht auf owned gesetzt.

@Himitsu: :oops: so tief will ich garnicht reingehen, aber trotzdem danke für diesen Tiefenblick.

Was wird eigentlich alles freigegeben, wenn die procedure zu Ende ist, in der ich die TJSON-Objekte erzeuge?
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)?

Edit:
Ich habe ein seltsamens Phänomen mit dem Inhalt von meiner json-Variable. Ich beobachte sie durch die Auswertung von json.toString.

Delphi-Quellcode:

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

      json.AddPair('path', jsonArr);

Bis hier steht in meinem json.toString:
'{"is_left_test_point":true,"installation_info":"" ,"path":[{"is_agc_on":false,"att_post":0,"eol":-7},{"is_agc_on":false,"att_post":0,"eol":1}]}'

Dann wird das ausgeführt:

Delphi-Quellcode:

    finally
     jsonArr.Free;
     jsonArr:=nil;
    end;

In dem Moment, wo jsonArr.Free gesetzt wird, ändert sich die json.toString zu:
'{"is_left_test_point":true,"installation_info":"" ,"path":{"is_left_test_point":true,"installation_i nfo":"",}'

Wie kann das denn sein?!?

[himitsu]

ReportMemoryLeaksOnShutdown := True;

Siehe FastMM Debug-Optionen

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

[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:

[Uwe Raabe]

Zitat:

Zitat von SearchBot (Beitrag 1509413)

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

Nein! Das geht nicht.

Und übrigens ist UnicodeString überhaupt nicht blöd! Kann er auch gar nicht sein, denn das Attribut blöd kann zwar Menschen und ihren Ideen zugeordnet werden, aber keinen Datentypen.

[SearchBot]

Zitat:

Zitat von Uwe Raabe (Beitrag 1509415)

Und übrigens ist UnicodeString überhaupt nicht blöd! Kann er auch gar nicht sein, denn das Attribut blöd kann zwar Menschen und ihren Ideen zugeordnet werden, aber keinen Datentypen.

Okay, Entschuldigung.
Ich meinte mit "blöd", daß dieser Typ für mich neue Schwierigkeiten verursacht, einfach ausgedrückt.

Für alle anderen und jedes neue Projekt ist es bestimmt ein sehr hilfreicher und zukunftsorientierter Zeichenketten-Typ.

[KodeZwerg]

Zitat:

Zitat von Uwe Raabe (Beitrag 1509415)

Zitat:

Zitat von SearchBot (Beitrag 1509413)

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

Nein! Das geht nicht.

Zumindest kann er auf ein Delphi vor D2009 downgraden um wieder sein geliebten AnsiString überall als default zu haben, ob es sinnvoll ist mag ich bezweifeln.

[himitsu]

Es gibt (leider) nur den TStringHelper für String/UnicodeString.

WideString, AnsiString und alle AnsiString-Ableger ala UTF8String sind davon "befreit".
Ebenfalls bei sowas wie TComponent.Caption geht es nicht, denn obwohl es ein String-Nachfahre ist, kennt TCaption den StringHelper nicht.


Alternativ muß man nach string(..) casten, um an den Helper zu kommen.

[SearchBot]

Okay :thumb:

Ich habe also eure Anregungen im Quelltext beachtet und so ein paar Macken beheben können, Leaken tut es am Ende immernoch, aber es führt nicht zum Absturz des Programms.

Wenn sich das TJSONzeugs innen also selbst aufräumt, kann ich als Unwissender kaum etwas dagegen machen, wenn es dann trotzdem leakt. :wink:
Ich gebe also nur das Objekt free, das ich zu Beginn create habe.
Es übersteigt leider mein Verständnis, wie sich das so zusammenschiebt, daß es am Ende nur 1 free brauchen soll, um alles wieder aufzulösen. Ist natürlich praktisch, wenn es wirklich so funktionieren sollte, denn im FastMM werden diese Objekte trotzdem häufig als Leak gemeldet - wie es auch etliche andere Nutzer vor mir hier im Forum immer wieder entdeckt haben.

Dankeschön und frohes Wochenende!
:dp: