Verständnisfrage: TJSONObject create/free/destroy?

[himitsu]

ReportMemoryLeaksOnShutdown := True;

Siehe FastMM Debug-Optionen

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

[SearchBot]

Zitat von himitsu:

ReportMemoryLeaksOnShutdown := True;

Siehe FastMM Debug-Optionen

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

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

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...

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!?

[TiGü]

Zitat von SearchBot:

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

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...

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" 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 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 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.



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

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.

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..

[Uwe Raabe]

Zitat von SearchBot:

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 von Uwe Raabe:

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 von Uwe Raabe:

Zitat von SearchBot:

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.