Memoryleak oder fatale Exception bei TJSONObject.RemovePair

[TiGü]

Zitat von t2000:

Das werde ich ausprobieren.
Ich hatte die Information von 2 unterschiedlichen Stellen. (im Internet; und fragt bitte nicht wo; ich weiß es nicht mehr)

Aktuell liefert ChatGPT o3-mini-high dies hier:
Anhang 57430

DeepSeek sagt einen direkt, dass da in CheckXDataRef eine Dangling Reference existiert (so wie sie auch Uwe erkannt hat).

Zitat:

Mein Prompt:
Kontext ist Softwareentwicklung mit Delphi, speziell der Umgang mit JSON. Findest du im folgenden Quelltext mögliche Fehler?

...es folgt dann dein Codeabschnitt.

Zitat:

Hier sind die möglichen Fehler im Quelltext:

1. Dangling Reference in `CheckXDataRef`:
- **Problem**: Beim Hinzufügen des neuen JSON-Paars (`AddPair`) wird der Wert des ursprünglichen Paars (`AJSONObject.Values[AName]`) direkt übernommen. Nach dem Löschen und Freigeben des ursprünglichen Paars (`RemovePair(...).Free`) wird dieser Wert freigegeben, sodass das neue Paar auf ungültige Daten verweist.
- **Lösung**: Den Wert klonen (z. B. `AJSONObject.Values[AName].Clone`), um eine unabhängige Kopie zu erstellen.

Delphi-Quellcode:

   // Korrektur:
   AJSONObject.AddPair(AName + cXDataRef, AJSONObject.Values[AName].Clone);

2. Fehlende Typüberprüfung in `CheckIDValue`:
- **Problem**: `AJSONObject.Values[AName].AsType<String>` setzt voraus, dass der Wert ein String ist. Bei anderen Typen (Zahl, Boolesch) kommt es zu einer Exception.
- **Lösung**: Prüfung des Werttyps vor der Konvertierung:

Delphi-Quellcode:

   var
     LValue: TJSONValue;
   begin
     LValue := AJSONObject.Values[AName];
     if LValue is TJSONString then
       LIDValue := TJSONString(LValue).Value
     else
       raise Exception.Create('Unexpected type for ' + AName);

3. Irreführender Kommentar in CheckXDataRef:

Problem: Der Kommentar deutet an, dass AJSONObject nach RemovePair(...).Free ungültig sei, was nicht zutrifft. Das Objekt bleibt gültig, aber der Wert des neuen Paars ist betroffen (siehe Punkt 1).

4. Potenzielle Ausnahmen bei fehlenden Feldern:

Problem: Wenn ein Feld mit @-Präfix in AInsertArr/AFieldArr angegeben wird, das ursprüngliche Feld (LFeldname ohne @) aber nicht existiert, wird CheckXDataRef das @ref-Feld nicht anlegen, was zur Exception führt. Dies könnte eine falsche Annahme über die Datenintegrität sein.

### Zusammenfassung
Die kritischsten Fehler sind die **ungültige Referenz** in `CheckXDataRef` und die **fehlende Typüberprüfung** in `CheckIDValue`. Diese müssen korrigiert werden, um Speicherzugriffsfehler (Access Violations) und unerwartete Exceptions zu vermeiden.