Falscher Code bei der Kombination von anonymen und verschachtelten Prozeduren

Question

Ich habe einige unerwartete Zugriffsverletzungen für Delphi-Code, die ich für richtig halte, aber scheint falsch zu kompilieren. Ich kann es

reduzieren

procedure Run(Proc: TProc); 
begin 
    Proc; 
end; 

procedure Test; 
begin 
    Run(
    procedure 
    var 
     S: PChar; 

     procedure Nested; 
     begin 
     Run(
      procedure 
      begin 
      end); 
     S := 'Hello, world!'; 
     end; 

    begin 
     Run(
     procedure 
     begin 
      S := 'Hello'; 
     end); 
     Nested; 
     ShowMessage(S); 
    end); 
end; 

Was für mich passiert ist, dass S := 'Hello, world!' an der falschen Stelle speichert. Aus diesem Grund wird entweder eine Zugriffsverletzung ausgelöst, oder ShowMessage(S) zeigt "Hello" (und manchmal wird eine Zugriffsverletzung ausgelöst, wenn die Objekte freigegeben werden, die zum Implementieren anonymer Prozeduren verwendet werden).

Ich verwende Delphi XE, alle Updates installiert.

Woher weiß ich, wo dies zu Problemen führt? Ich weiß, wie ich meinen Code umschreiben kann, um anonyme Prozeduren zu vermeiden, aber ich habe Probleme herauszufinden, in welchen Situationen sie zu falschem Code führen, also weiß ich nicht, wo ich sie vermeiden soll.

Es wäre interessant zu wissen, ob dies in späteren Versionen von Delphi behoben ist, aber nichts mehr als interessant, Upgrade ist keine Option zu diesem Zeitpunkt.

Auf QC, den neuesten Bericht kann ich die ähnliche #91876 finden, aber das ist in Delphi XE gelöst.

aktualisieren:

Basierend auf AlexSC Kommentare, mit einer geringfügigen Änderung:

... 

     procedure Nested; 
     begin 
     Run(
      procedure 
      begin 
      S := S; 
      end); 
     S := 'Hello, world!'; 
     end; 

... 

funktioniert.

Der erzeugte Maschinencode für

S := 'Hello, world!'; 

im andernfalls Programm ist

ScratchForm.pas.44: S := 'Hello, world!'; 
004BD971 B89CD94B00  mov eax,$004bd99c 
004BD976 894524   mov [ebp+$24],eax 

während die richtige Version

ScratchForm.pas.45: S := 'Hello, world!'; 
004BD981 B8B0D94B00  mov eax,$004bd9b0 
004BD986 8B5508   mov edx,[ebp+$08] 
004BD989 8B52FC   mov edx,[edx-$04] 
004BD98C 89420C   mov [edx+$0c],eax 

Der generierte Code in das fehlerhafte Programm ist nicht zu sehen, dass S in eine vom Compiler generierte Klasseverschoben wurdeist wie auf externe lokale Variablen verschachtelter Methoden zugegriffen wird wie auf lokale Variablen zugegriffen wird.

Answer 1

Woher weiß ich, wo dies zu Problemen führt?

Es ist zu diesem Zeitpunkt schwer zu sagen.
Wenn wir die Art der Fehlerbehebung in Delphi XE2 wüssten, wären wir in einer besseren Position.
Sie können nur anonyme Funktionen verwenden.
Delphi hat prozedurale Variablen, daher ist die Notwendigkeit für anonyme Funktionen nicht so schlimm.
Siehe http://www.deltics.co.nz/blog/posts/48.

Es wäre für mich interessant zu wissen, ob diese in späteren Versionen von Delphi fixiert ist

Nach @Sertac Akyuz dies in XE2 behoben wurde.

Persönlich mag ich keine anonymen Methoden und musste Leute davon abhalten, sie in meinen Java-Projekten zu verwenden, weil ein großer Teil unserer Code-Basis anonym wurde (Event-Handler).
Bei extremer Moderation kann ich den Anwendungsfall sehen.
Aber in Delphi, wo wir prozedurale Variablen und verschachtelte Verfahren haben ... Nicht so sehr.

Answer 2

Ohne den ganzen Assembler-Code für das Ganze zu sehen (Prozedur Test) und nur auf dem von Ihnen geposteten Snippet angenommen, ist es wahrscheinlich, dass auf dem fehlerhaften Snippet nur ein Pointer verschoben wurde, wo auf der richtigen Version auch einige Daten verschoben sind .

So scheint es, dass S: = S oder S: = '' bewirkt, dass der Compiler eine eigene Referenz erstellt und sogar etwas Memory zuweisen könnte, was erklären würde, warum es dann funktioniert.

Ich gehe auch davon aus, dass eine Zugriffsverletzung ohne S: = S oder S: = 'auftritt, weil, wenn kein Speicher für die Zeichenfolge reserviert ist (erinnern Sie sich nur S: PChar deklariert), eine Zugriffsverletzung ausgelöst wird weil auf nicht zugewiesenen Speicher zugegriffen wurde.

Wenn Sie einfach S: String deklarieren, wird dies wahrscheinlich nicht passieren.

Zugänge nach längerer Kommentar:

A PChar auf die Datenstruktur nur ein Zeiger ist, existieren, müssen. Ein weiteres häufiges Problem bei PChar ist es, lokale Variablen zu deklarieren und dann einen PChar an diese Variable zu anderen Procs zu übergeben, denn die lokale Variable wird freigegeben, sobald die Routine beendet ist, aber der PChar wird immer noch darauf zeigen, die dann erhöht Zugriffsverletzungen, auf die einmal zugegriffen wurde.

Die einzige Möglichkeit, die per Dokumentation existiert, ist, so etwas zu deklarieren const S: PChar = 'Hello, world!' dies funktioniert, weil der Compiler eine relative Adresse zu ihm auflösen kann. Aber das funktioniert nur für Konstanten und nicht für Variablen wie im obigen Beispiel. Wenn Sie wie im obigen Beispiel vorgehen, muss Storage für das String-Literal reserviert werden, auf das der PChar dann auf S:String; P:PChar; S:='Hello, world!'; P:=PChar(S); oder ähnlich verweist.

Wenn es noch immer mit der Deklaration von String oder Integer fehlschlägt, verschwindet die Variable irgendwo irgendwo oder plötzlich nicht mehr in einem Proc, aber das wäre ein anderes Problem, das nichts mit dem bereits existierenden PChar-Problem zu tun hat.

Schluss Fazit:

Es ist möglich, S:PChar; S:='Hello, world!' zu tun, aber der Compiler dann einfach ordnet sie als lokale oder globale Konstante wie const S: PChar = 'Hello, world!' hat, die in Executable gespeichert wird, erstellt eine zweite S := 'Hello' dann eine andere, die auch in gespeichert Executable und so weiter - aber S zeigt dann nur auf den letzten zugewiesenen, alle anderen sind noch in der ausführbaren Datei, aber nicht mehr zugänglich, ohne den genauen Standort zu kennen, weil S nur auf den letzten zugewiesenen Punkt zeigt.

Also abhängig davon war die letzte S Punkte entweder Hello, world! oder Hello.Auf dem obigen Beispiel kann ich nur raten, welcher der letzte war und wer weiß, vielleicht kann der Compiler auch nur raten und je nach Optimierungen und anderen unvorhersehbaren Faktoren S könnte plötzlich auf nicht zugeordnete Mem statt auf die letzte durch die Zeit was ausgeführt wird Dann wird eine Zugriffsverletzung ausgelöst.