Access violation bei Zugriff auf eine PUBLIC-Variable

[GueAck]

Hallo,

ich habe in dem dargestellten Code eine Merkwürdigkeit: In der dargestellten Form läuft alles bestens. Wenn ich aber die Variable "Filename" in den PUBLIC-Teil verlege, dann wird die erste Datei richtig geöffnet und bearbeitet, aber beim öffnen der nächsten (!) Datei in "OpennextFil_der_Liste" gibt die Exception "Im Projekt Auflisten.exe ist eine Exception der Klasse $C0000005 mit der Meldung 'access violation at 0x0027a67e: read of address 0x3ca2427f'.". Im Aufruf-Stack der IDE (Delphi 12) steht als oberster Eintrag "@UStrAsG + $32".

Wenn ich auf die Zeile "Filename := f_Liste[..] einen Breakpoint setze, dann sehe ich beim ersten Aufruf, dass Filename ein leerer String ist, beim zweiten Auruf zeigt mir aber der Debugger an "Nicht verfügbarer Wert". Wie kann das sein?

Den Code habe ich vor vielen Jahren gemacht, vermutlich noch unter Delphi 7, da ist er (mit Filename im PUBLIC-Teil) sauber gelaufen.

Hat jemand eine Tdee, was die Ursache ist oder was ich falsch gemacht habe?

Grüße
GueAck

Delphi-Quellcode:

UNIT UfileListe;

INTERFACE
t_Urclass = CLASS
  PROCEDURE openfilefolge(vpfad: STRING); VIRTUAL; ABSTRACT;
  FUNCTION getzeile: boolean; VIRTUAL; ABSTRACT; {true: zeile vorhanden}
END;

t_fileListe = CLASS(t_Urclass)
  Filename: f_name; // in Public geht es nicht, das ergibt beim 2. Aufruf von opennextfild_der_luiste eine Access-violation UStrAsg
  PROCEDURE openfilefolge(vpfad: STRING); OVERRIDE;
  FUNCTION getzeile; OVERRIDE;
PRIVATE
  f_i, f_anz: integer; {Index des aktuellen Files in der f_liste }
  f_liste: ARRAY[1..fanzmax] OF STRING;
  FUNCTION opennextfile_der_liste: boolean; {True: Erfolg }
PUBLIC
  { Public-Deklarationen }
END;

IMPLEMENTATION

FUNCTION t_fileListe.getzeile;
VAR
  gefunden: boolean;
BEGIN
  // Liest alle Zeilen der aktuellen Datei ein.
  // Am Ende wird mit
  gelungen := opennextfile_der_liste;
  // die nächste Datei geöffnet.
  result := gelungen;
END;

FUNCTION t_fileArduino.opennextfile_der_liste;
BEGIN
  //...
  f_i := f_i + 1;
  Filename := f_liste[f_i]; // hier passiert der Fehler
  //...
END;

PROCEDURE t_fileArduino.openfilefolge(vpfad: STRING);
BEGIN
  // Die Nammen aller Dateien im Verzeichnis werden in die Liste f_liste eingetragen.
  f_i := 0;
  f_anz := Abzahl_der_vorhandenen_Dateien;
  opennextfile_der_luste;
END;

END.

[Uwe Raabe]

Wie ist denn f_name deklariert?

[himitsu]

Zitat:

in Public geht es nicht,

Egal, ob PUBLIC davor steht, oder nicht ... für deine Klassen ist die StandardSichtbarkeit zu Beginn immer PUBLIC (im Modus {$M+} wäre der Standard PUBLISHED)
Und egal, ob PUBLIC, oder was Anderes, am Grund diese Fehlers wird es nichts ändern.

Was ist f_name?

Wirklich beim Schreib-Zugriff auf Filename?
Oder vielleicht doch schon beim Lese-Zugriff auf f_liste? (ich bin mir ganz sicher, dass es der Lesezugriff ist )

Da f_liste keine Referenz ist, entfällt die Prüfung, ob diese Instanz richtig erstellt wurde (z.B. TList, dynamisches Array oder sonstwas)

Wurde die Instanz deiner Klassen Objekte (t_fileListe) auch ordnungsgemäß erstellt und ist deren Variable gültig?






Bonus:
Warum heißt getzeile nicht istzeilevorhanden? (jedenfalls besagt sein Kommentar, dass sie so heißen sollte )
Dir sollte doch aufgefallen sein dass ein Kommentar nötig war {true: zeile vorhanden}, um zu sagen, dass diese Funktion nicht die Zeile zurückgibt, sondern nur etwas über deren Existenz aussagt.
Bzw. eigentlich würde sie wohl eher allezeileneinlesen heißen und dann wäre auch so klar, dass das Result "erfolgreich" bedeuten wird.

Zitat:

Variable

Das ist ein "Feld" (Field) der Klasse / des Objekts.
"Eigenschaften" (Property) haben Property davor stehen.

PS: Deswegen benennen viele ihre Fields auch mit F am Anfang. (wie bei Klassen, also Types mit T)

[GueAck]

Danke schon einmal.

a) f_name = string;

b) Auch die Variable f_liste gehört ja zur Klasse t_Fileliste. Beim zweiten Aufruf zeigt mir der Debugger für f_Liste[fi] auch das richtige an, nur Dilename kann er nicht mehr anzeigen. Und das Verschieben der Definition von filename von PUBLIC nach oben hat ja Erfolg gebracht. Es muss also am Schreibzugriff liegen.

c) Namen: Da kann man sicher einiges verbessern. Zu "getzeile": Zig Zeilen Code habe ich hier durch einen Kommentar "// Liest alle Zeilen der aktuellen Datei ein." ersetzt. Exakter wäre "// Liest bei jedem Aufruf eine Zeile der aktuellen Datei ein." und ich hätte ergänzen können "dann ist gelungen = true".

d) t_filelist im ONCREATE des Hauptprogramms erzeugt und bei ONDESTROY freigegeben. Wenn das Objekt zu t_fileliste gelöscht worden wäre, dann hätte ja schon der Aufruf von getzeile eine Exception erzeugt.

Grüße
GueAck

[Uwe Raabe]

Dem gezeigte Code fehlt noch ein Type Keyword. Das und ein Haufen anderer Dinge zeigen, dass es nicht der vollständige Code ist. Kannst du das Problem an einem minimalen Beispiel nachstellen?

Instinktiv würde ich mal prüfen, ob die Instanz der Klasse nicht vor dem Aufruf freigegeben wird.

[himitsu]

Was ist fanzmax?

> zeigen, dass es nicht der vollständige Code ist
Stell dir mal vor, wie viele Fragen nicht nötig gewesen wären, @GueAck

Zitat:

b) ... Beim zweiten Aufruf zeigt mir der Debugger für f_Liste[fi] auch das richtige an, nur Dilename kann er nicht mehr anzeigen. Und das Verschieben der Definition von filename von PUBLIC nach oben hat ja Erfolg gebracht. Es muss also am Schreibzugriff liegen.

Man könnte auch in Richtung Buffer-Overflow nachdenken,
> wenn filename nach f_liste steht, dann stimmt was nicht

Wenn du z.B. in f_liste rein schreibst, aber in einen Index, welchen es nicht gibt, dann ginge natürlich irgendwas Anderes kaputt (z.B. das filename, wenn es dahinter liegt )



Wie wäre es, wenn du in den Projektoptionen mal die Bereichsprüfung und Überlaufprüfung aktivierst?

Oder oben in deine Unit Folgendes einfügen

Delphi-Quellcode:

{$OVERFLOWCHECKS ON}
{$RANGECHECKS ON}

PS: In einem etwas aktuelleren Delphi sind diese Optionen, in neu erstellten Projekten, standardmäßig aktiv. (weil ständig jemand Scheiße baut)

[Uwe Raabe]

Zitat von himitsu:

Man könnte auch in Richtung Buffer-Overflow nachdenken,
> wenn filename nach f_liste steht, dann stimmt was nicht

Wenn du z.B. in f_liste rein schreibst, aber in einen Index, welchen es nicht gibt, dann ginge natürlich irgendwas Anderes kaputt (z.B. das filename, wenn es dahinter liegt )

An das hatte ich auch schon gedacht und ich würde hier mal vor dem Zugriff den Index überprüfen:

Delphi-Quellcode:

  f_i := f_i + 1;
  Filename := f_liste[f_i]; // hier passiert der Fehler

[GueAck]

Hallo,

jetzt habe ich eine abgespeckte Version meines Programms gemacht, da habe ich (oder wollte ich) nur alles löschen, was mit der Interpretation der aus den Dateien gelsenen Daten zu tun hat; ich gebe einfach nur die ersten 10 Byte jeder Datei im Memo1 aus. Der abgespeckte Code läuft, aber: Den Fehler gibt es nicht mehr!!! Also nützt auch die abgespeckte Version nichts.

Zu der Frage Feldindex außerhalb des Bereiches: Laufzeitfehler sind im Compiler alle aktiviert.

Jedenfalls habe ich jetzt einen Ansatzpunkt.

Ich melde mich, wenn ich die Lösung gefunden habe, wird aber etwas dauern.

Danke jedenfalls für die vielen Anregungen.

Grüße
GueAck

[Blup]

Vermutlich wurde die Klasse t_fileArduino von t_fileListe abgeleitet, aber die Deklaration fehlt.
Es fehlt ebenfalls die Implementation wo die Instance der Klasse erzeugt und benutzt wird.

Zitat:

// in Public geht es nicht, das ergibt beim 2. Aufruf von opennextfild_der_luiste eine Access-violation UStrAsg

Alles deuted darauf hin das es sich nicht um einen 2. Aufruf handelt, sondern 2 verschiedene Methoden mit dem selben Namen aufgerufen werden.

t_fileListe.opennextfile_der_liste(); // wird von getzeile() aufgerufen
t_fileArduino.opennextfile_der_liste(); // wird von openfilefolge() aufgerufen;

opennextfile_der_liste() müsste eigentlich als virtual bzw. override deklariert werden.
Aus dem Code wird auch nicht klar, warum es überhaupt eine Unterscheidung zwischen getzeile und opennextfile_der_liste gibt.

[GueAck]

Hallo,
das Problem ist verschwunden, ich kann aber nicht sagen woran es gelegen hat. Zwar habe ich zwischenzeitlich gefunden, dass es zwei der verwendeten *.PAS-Dateien in verschiedenen Versionen auf meinem Rechner gab. Die *Pas Dateien sind nicht in das Projekt eingebunden sondern werden als *.dcu dazu gelinkt. Aber wenn da was nicht gepasst hätte, dann hätten das der Compiler oder Linker gemeldet, außerdem haben die Unterschiede zwischen den Versionen nichts mit dem eigentlichen Problem zu tun. Immerhin würde das aber erklären, warum meine abgespeckte Version, die ich für das Forum vorbereitet hatte, und für die ich alles in einer *.Pas-Datei zusammengefasst habe, ohne Probleme lief.

Danke nochmals für die Anregungen,
Grüße GueAck