Delphi 6 -> Delphi 10.2

[Temi00]

Hallo Forum,
ist wahrscheinlich einfach aber ich Möchtegern-Delphi-Programmierer weiß grad mal wieder nicht weiter. Wir hatten bis vor kurzen in der Firma Delphi 6 und jetzt Delphi XE 10.2 Tokyo gekauft. Das Project extern durch ein Freelancer auf 10.2 hieven lassen. Hat auch funktioniert. Danach hatten sich ein paer ZQueries noch über verschiedene Datentypen beschwert. Das konnte ich beheben. Ich konnte auch das Project übersetzen und laufen lassen.

Danach habe ich in dem rechten Balken in den Projektoptionen den Buildpfad geändert. Und in den Optionen Editor Smarttabs eingeschaltet. Plötzlich kann ich das Projekt nicht mehr Übersetzen und der Debugger springt zu ZTokenizer. Ich kann machen was ich will. In der Versionskontrolle auf eine frühere Version gehen hilft auch nicht. Alles löschen und die sourcen von dem externen Entwickler zu nehmen bringt den selben Fehler. Mache ich aber ein völlig neues Projekt (Ein Formular, DBGrid und die dazugehörigen Datenbank-Komponenten. Das geht.

Ich habe also folgende Bild:

gehe ich zu einem früheren Quellcode habe ich den Fehler immer noch. Kann also nicht in den Sourcen liegen. Habe ich doch irgebdwas in den Einstellungen von Delphi geändert.

Mache ich aber ein völlig neues Projekt mit den Zeos-Komponenten. Dann funktioniert das???

Neben bei weiß einer ein gutes Buch für Delphi 10.2 oder Online Video-Kurs der speziell auf Debugging auch eingeht?
aber eigentlich bräuchte ich auch OO-Programmieren allgemein. sonst wurschtel ich hier ewig weiter ;-)

also wenn ich mit F9 starte kommt am ende Folgende Meldung

Project azShop.exe raised exception class $C0000005 with message 'access violation at 0x006c7022: read of address 0x00000004'.

Klicke ich auf Break

Thread Start: Thread ID: 4228. Process azShop.exe (8852)
Process Start: C:\Users\Micha\Documents\dev\Tokyo-Source\amorebioshop7\dev\azShop\azShop.exe. Base Address: $00400000. Process azShop.exe (8852)
Module Load: azShop.exe. Has Debug Info. Base Address: $00400000. Process azShop.exe (8852)
Module Load: ntdll.dll. No Debug Info. Base Address: $774F0000. Process azShop.exe (8852)
Module Load: KERNEL32.dll. No Debug Info. Base Address: $76FC0000. Process azShop.exe (8852)
Module Load: KERNELBASE.dll. No Debug Info. Base Address: $74470000. Process azShop.exe (8852)
Module Load: COMDLG32.dll. No Debug Info. Base Address: $74C70000. Process azShop.exe (8852)
Thread Start: Thread ID: 5512. Process azShop.exe (8852)
Module Load: msvcrt.dll. No Debug Info. Base Address: $76E10000. Process azShop.exe (8852)
Module Load: WINMM.dll. No Debug Info. Base Address: $70410000. Process azShop.exe (8852)
Module Load: WINSPOOL.DRV. No Debug Info. Base Address: $737C0000. Process azShop.exe (8852)
Module Load: combase.dll. No Debug Info. Base Address: $77180000. Process azShop.exe (8852)
Module Load: ucrtbase.dll. No Debug Info. Base Address: $746A0000. Process azShop.exe (8852)
Module Load: RPCRT4.dll. No Debug Info. Base Address: $76AB0000. Process azShop.exe (8852)
Module Load: WINMMBASE.dll. No Debug Info. Base Address: $702C0000. Process azShop.exe (8852)
Thread Start: Thread ID: 1392. Process azShop.exe (8852)
Module Load: CFGMGR32.dll. No Debug Info. Base Address: $76DD0000. Process azShop.exe (8852)
Module Load: IPHLPAPI.DLL. No Debug Info. Base Address: $73B10000. Process azShop.exe (8852)
Module Load: bcrypt.dll. No Debug Info. Base Address: $73E00000. Process azShop.exe (8852)
Module Load: SspiCli.dll. No Debug Info. Base Address: $73F10000. Process azShop.exe (8852)
Thread Start: Thread ID: 7564. Process azShop.exe (8852)
Module Load: CRYPTBASE.dll. No Debug Info. Base Address: $73F00000. Process azShop.exe (8852)
Module Load: bcryptPrimitives.dll. No Debug Info. Base Address: $76F60000. Process azShop.exe (8852)
Module Load: SECHOST.dll. No Debug Info. Base Address: $74650000. Process azShop.exe (8852)
Module Load: SHCORE.dll. No Debug Info. Base Address: $75510000. Process azShop.exe (8852)
Module Load: USER32.dll. No Debug Info. Base Address: $76C00000. Process azShop.exe (8852)
Module Load: win32u.dll. No Debug Info. Base Address: $76F10000. Process azShop.exe (8852)
Module Load: GDI32.dll. No Debug Info. Base Address: $743B0000. Process azShop.exe (8852)
Module Load: gdi32full.dll. No Debug Info. Base Address: $74250000. Process azShop.exe (8852)
Module Load: msvcp_win.dll. No Debug Info. Base Address: $743E0000. Process azShop.exe (8852)
Module Load: SHLWAPI.dll. No Debug Info. Base Address: $77090000. Process azShop.exe (8852)
Module Load: SHELL32.dll. No Debug Info. Base Address: $75610000. Process azShop.exe (8852)
Module Load: Windows.Storage.dll. No Debug Info. Base Address: $74D60000. Process azShop.exe (8852)
Module Load: COMCTL32.dll. No Debug Info. Base Address: $71EF0000. Process azShop.exe (8852)
Module Load: ADVAPI32.dll. No Debug Info. Base Address: $77460000. Process azShop.exe (8852)
Module Load: AppCore.dll. No Debug Info. Base Address: $76F30000. Process azShop.exe (8852)
Module Load: POWRPROF.dll. No Debug Info. Base Address: $76D80000. Process azShop.exe (8852)
Module Load: profapi.dll. No Debug Info. Base Address: $74C50000. Process azShop.exe (8852)
Module Load: OLEAUT32.dll. No Debug Info. Base Address: $770E0000. Process azShop.exe (8852)
Module Load: ole32.dll. No Debug Info. Base Address: $769B0000. Process azShop.exe (8852)
Module Load: VERSION.dll. No Debug Info. Base Address: $728F0000. Process azShop.exe (8852)
Module Load: NETAPI32.dll. No Debug Info. Base Address: $73790000. Process azShop.exe (8852)
Module Load: netutils.dll. No Debug Info. Base Address: $73770000. Process azShop.exe (8852)
Module Load: IMM32.dll. No Debug Info. Base Address: $76EE0000. Process azShop.exe (8852)
Module Load: MSCTF.dll. No Debug Info. Base Address: $74100000. Process azShop.exe (8852)
Module Load: UxTheme.dll. No Debug Info. Base Address: $71DA0000. Process azShop.exe (8852)
Module Load: dwmapi.dll. No Debug Info. Base Address: $71E30000. Process azShop.exe (8852)
Module Load: WTSAPI32.dll. No Debug Info. Base Address: $73880000. Process azShop.exe (8852)
Module Load: WINSTA.dll. No Debug Info. Base Address: $73830000. Process azShop.exe (8852)
First chance exception at $006C7022. Exception class $C0000005 with message 'access violation at 0x006c7022: read of address 0x00000004'. Process azShop.exe (8852)

sagt das irgendwem was?

Was konn ich noch an hilfreichen Informationen liefern? (Bitte auch miteilen wie ich die erzeuge ;) )

Danke schon mal für eure Hilfe
Temi

[himitsu]

Erstmal solltest du mit dem Debugger schauen was los ist.

"access violation at 0x006c7022: read of address 0x00000004"

0x006c7022 ist die Stelle des Fehlers im code/Programm

Und bei 0x00000004 konnte nicht zugrgriffen werden, was auch klar ist, da die Adressen $00000000 bis $0000FFFF niemals existieren (außer in Treibern)

$00000004 = nil + Offset_ZBzurVariableOderPropertyInEinemObjekt



ACHTUNG: Die Fehlerzeile kann auch manchmal die Codezeile über der markierten Stelle sein.
Vor allem wenn man über den Stack-Trace sucht, denn da stehen die Rücksprungadressen drin, also de Befehl danach und auch der Debugger verrutscht manchmal ein bissl.

Meine Vermutung Current oder Children ist NIL.
Jetzt mußt du nur noch rausbekommen, warum das so ist. (dort suchen, wo es erstellt/zugewiesen wurde)
[edit] da Current auf NIL geprüft wird, wird es wohl das Children in der Zeile davor sein

[KodeZwerg]

Könnte auch totaler Quark sein den ich hier von mir gebe:
Hast Du eventuell als Ziel-Platform von 32 auf 64 bit gewechselt?
(Falls gefragt war was ein guter/übersichtlicher Debugger ist, ich kann den von HexRay's empfehlen.)

[jaenicke]

Zitat:

Zitat von KodeZwerg (Beitrag 1398139)

(Falls gefragt war was ein guter/übersichtlicher Debugger ist, ich kann den von HexRay's empfehlen.)

Viel sinnvoller ist doch der in Delphi integrierte, wenn man den wie hier zur Verfügung hat. Da kannst du schließlich auf Quelltextebene statt auf Assemblerebene debuggen soweit möglich, aber wenn nötig auch auf Assemblerebene weitermachen.

[HeZa]

Ich befrage mal die Glaskugel:

Die Exception passiert durch den Aufruf von

Delphi-Quellcode:

Current := Children[i];

und zwar deswegen, weil es die erste Stelle in der Funktion ist, die auf eine Instanz-Daten deiner Klasse zugreift. Leider ist deine Instanz (vom Typ TZSymbolNode) nicht initzialisiert.

Suche also die Stelle wo deine Instanz erstellt werden sollte.

Erster Versuch: Wenn du im Debugger an der Stelle ankommst, gehe den Aufrufstack Schritt für Schritt hoch.

Zweiter Versuch: Suche nach Stelllen

Delphi-Quellcode:

TZSymbolNode.Create

. Vielleich findest du so was wie:

Delphi-Quellcode:

var
  node: TZSymbolNode;
begin
  if xxx then
    node: TZSymbolNode.Create;
    node.FindChildWithChar(); // hier ist node evtl. nicht Initzialisiert
end;

Dritter Versuch: Nimm FastMM zu Hilfe.

[MichaelT]

Kurzschlussauswertung zieht nicht. Die Logik wirkt ein wenig kühn.

Zitat:

Zitat von himitsu (Beitrag 1398131)

Meine Vermutung Current oder Children ist NIL.
Jetzt mußt du nur noch rausbekommen, warum das so ist. (dort suchen, wo es erstellt/zugewiesen wurde)
[edit] da Current auf NIL geprüft wird, wird es wohl das Children in der Zeile davor sein

[himitsu]

Zitat:

Zitat von MichaelT (Beitrag 1398206)

Kurzschlussauswertung zieht nicht. Die Logik wirkt ein wenig kühn.

Wieso?
Anhand der vorhandenen Informationen, passt das schon.

Mit mehr/genaueren Infos ... wer weiß.

[Temi00]

Hallo Forum,
nein als Zielplattform ist weiter 32bit eingestellt.

Ich habe ja in den Zeos sourcen überhaupt nichts geändert.

Kenne leider die Objectorientierte Programmierung nicht (Hab bisher meist PHP funktionale Programmierung - allerhöchstens objectbasiert aber nicht objectorientiert programmiert)

Delphi-Quellcode:

function TZSymbolNode.FindChildWithChar(Value: Char): TZSymbolNode;
var
  I: Integer;
  Current: TZSymbolNode;
begin
  Result := nil;
  for I := 0 to 255 do
  begin
    Current := Children[I];  <------- 
    if (Current = nil) or (Current.Character = Value) then
    begin
      Result := Current;
      Break;
    end;
  end;
end;

Woher kommt den die Variable Children? Ist das eine globale Variable? Ich denke nicht muß wohl was wie Childs vom Objekt TZSymbolNode sein?
Ja laut Debugger sind da 256 member(?) von Children nil

Ich suche jetzt also wie vorgeschlagen nach

TZSymbolNode.Create

Delphi-Quellcode:

// also finde ich hier

constructor TZSymbolNode.Create(Parent: TZSymbolNode; Character: Char);
begin
  FParent := Parent;
  FCharacter := Character;
  FValid := False;
  SetLength(FChildren, 256);
end;

// und hier


constructor TZSymbolRootNode.Create;
var
  I: Integer;
begin
  inherited Create(nil, #0);

  for I := 0 to 255 do
  begin
    FChildren[I] := TZSymbolNode.Create(Self, Chr(I));
    FChildren[I].Valid := True;
  end;
end;

wenn man den Aufrufstack anschaut (siehe Anhang) kann man vieleicht das ganze verkürzen? den wie gesagt am Quellcode der Zeos Komponenten habe ich nichts geändert.

sorry für die blutigen Anfängerfragen.

[mkinzler]

Ist einstellbar

http://docwiki.embarcadero.com/RADSt...iler-Direktive)

[Temi00]

Zitat:

Zitat von MichaelT (Beitrag 1398219)

In Delphi ist im Gegensatz zu Pascal die Kurzschlussauswertung allein am AND definiert und nicht am OR

ist zwar off topic aber IMHO muss man beim AND immer beide Ausdrücke auswerten beim OR kann auch wegoptimiert werden. Unwahrscheinlich dass das bei Pascal anders war. Just my 2 cents ;)

[MichaelT]

Nein. Ein Nuller genügt beim AND. Nur T AND T is T. Ist bei OR nicht anders.

[MichaelT]

Irrtum (meinerseits).

Zitat:

Zitat von mkinzler (Beitrag 1398220)

Ist einstellbar

http://docwiki.embarcadero.com/RADSt...iler-Direktive)

[FaTaLGuiLLoTiNe]

:?

Bei der verkürzten Auswertung bricht der Programmfluss ab, sobald klar ist, dass der gesamte boolsche Ausdruck wahr ist.

Bei deinem Beispiel ist doch der erste Operand des or-Vergleichs False und er kann die Auswertung nicht abbrechen, weil er auf jeden Fall noch den zweiten Operand auswerten muss um zu sehen ob dieser den Gesamtausdruck wahr macht...
wenn der erste Vergleich stattdessen True ergeben würde, dann würde der zweite Vergleich nicht mehr durchgeführt werden.

[MichaelT]

Hast du recht. Delphi bricht tatsächlich ab. Ich bin davon ausgegangen, dass das Pragma funktioniert. Da ließ ich mich verwirren. Sorry.

Zitat:

Zitat von FaTaLGuiLLoTiNe (Beitrag 1398225)

:?

Bei der verkürzten Auswertung bricht der Programmfluss ab, sobald klar ist, dass der gesamte boolsche Ausdruck wahr ist.

Bei deinem Beispiel ist doch der erste Operand des or-Vergleichs False und er kann die Auswertung nicht abbrechen, weil er auf jeden Fall noch den zweiten Operand auswerten muss um zu sehen ob dieser den Gesamtausdruck wahr macht...
wenn der erste Vergleich stattdessen True ergeben würde, dann würde der zweite Vergleich nicht mehr durchgeführt werden.

[MichaelT]

Ich hatte keinen Clean gemacht. Deswegen war ich auch überrascht.

Wenn der besagte Fehler auftritt, dann müsste man mal in die Projektoptionen schauen. Und hernach Clean und Build, zumindest zur Vorsicht.

Ändert aber nix dran dass der Code ein wenig seltsam ist.

Zitat:

Zitat von FaTaLGuiLLoTiNe (Beitrag 1398225)

:?

Bei der verkürzten Auswertung bricht der Programmfluss ab, sobald klar ist, dass der gesamte boolsche Ausdruck wahr ist.

Bei deinem Beispiel ist doch der erste Operand des or-Vergleichs False und er kann die Auswertung nicht abbrechen, weil er auf jeden Fall noch den zweiten Operand auswerten muss um zu sehen ob dieser den Gesamtausdruck wahr macht...
wenn der erste Vergleich stattdessen True ergeben würde, dann würde der zweite Vergleich nicht mehr durchgeführt werden.

[himitsu]

Zitat:

Zitat von Temi00 (Beitrag 1398221)

ist zwar off topic aber IMHO muss man beim AND immer beide Ausdrücke auswerten beim OR kann auch wegoptimiert werden. Unwahrscheinlich dass das bei Pascal anders war. Just my 2 cents ;)

Nein.

Mit der standardmäßigen kurzen Auswertung:
Bei OR wird der zweite nur ausgewertet, wenn der erste FALSE ist
Bei AND wird der zweite nur ausgewertet, wenn der erste TURE ist

Ansonsten steht das Ergebnis ja schon fest und Delphi spart sich die weitere Auswertung.
false AND irgendwas = false
true OR irgendwas = true

Darum kann man in Delphi standardmäßig auch sowas machen

Delphi-Quellcode:

if Assigned(irgendwas) and irgendwas.wasanderes then

Bei anderen Sprachen, die immer voll auswerten, oder wo die Auswertereihenfolge sich ändern kann, da geht das nicht.
z.B. in einigen DBMS (SQL), wo immer vollständig ausgewertet wird und wo der Queryplaner nach Gutdünken die Auswertung umdrehen kann.

[DeddyH]

Im zitierten Text stand doch nichts anderes.

[MichaelT]

Der Fehler sofern dieser dort auftritt kommt aber genau von der Abwesenheit der Kurzschlussauswertung. Wenn der Autor sonst nichts angegriffen hat.

Das war ein Reply auf meinen Irrtum, obwohl dieser auch nur teilweise zuschlug.

Ich hatte mich nur kurzfristig davon ablenken lassen, dass das Pragma nicht mehr funktioniert sondern die Einstellung auf das Projekt bezogen ist. Ich habe zwar dann geschnallt, dass die Pragmas offensichtlich überlesen werden, vermute ich zumindest, aber nicht regelmäßig einen Clean vor dem Build nach dem Umschalten der Projekt Settings.

Der Grund wäre der naheliegende. Stellt sich die Frage warum? Im Projekt global aufgedreht, da Projekt konvertiert - wäre möglich kann ich aber nicht testen.

Wenn dem nicht so wäre beleibt die Frage ob das Pragma {B+] doch irgendwie zieht wenn es im Quellcode steht. Wenn ja, dann muss jedes Element initialisiert gewesen sein. Sonst kann der Code nicht zu dem vermuteten Fehler passen.

Davon mal abgesehen

Delphi-Quellcode:

if (Current <> nil) and (Current.Character = Value) then ...

War einfacher zu lesen. Result ist zu Beginn schon nil.


Bei einem neuen Projekt funktionierts es. Also bleibt nicht viel.

erweiterte Variante (abenteuerlich): Complete Boolean avail gelte hieße, dass immer ein initialisiertes Objekt vor gefunden wurde und die Value. Wäre das der Fall gewesen, dann müsste sich am Aufbau des Baums etwas geändert haben, resp. an der Quelle aus der dieser Baum wird erzeugt.

zum Code: Es genügte vollkommen in einer Schleife zu prüfen ob das Objekt initialisiert ist und drinnen einfach die Value abzufragen. Es wird allein beim ersten Auffinden einer Value die Schleife verlassen. Sauberer wäre eine Variable canContinue und wenn man den nächsten Nachfolger liest diese zu setzen in Abhängigkeit ob die Value gefunden wurde.

Zitat:

Zitat von himitsu (Beitrag 1398241)

Zitat:

Zitat von Temi00 (Beitrag 1398221)

ist zwar off topic aber IMHO muss man beim AND immer beide Ausdrücke auswerten beim OR kann auch wegoptimiert werden. Unwahrscheinlich dass das bei Pascal anders war. Just my 2 cents ;)

Nein.

Mit der standardmäßigen kurzen Auswertung:
Bei OR wird der zweite nur ausgewertet, wenn der erste FALSE ist
Bei AND wird der zweite nur ausgewertet, wenn der erste TURE ist

Ansonsten steht das Ergebnis ja schon fest und Delphi spart sich die weitere Auswertung.
false AND irgendwas = false
true OR irgendwas = true

Darum kann man in Delphi standardmäßig auch sowas machen

Delphi-Quellcode:

if Assigned(irgendwas) and irgendwas.wasanderes then

Bei anderen Sprachen, die immer voll auswerten, oder wo die Auswertereihenfolge sich ändern kann, da geht das nicht.
z.B. in einigen DBMS (SQL), wo immer vollständig ausgewertet wird und wo der Queryplaner nach Gutdünken die Auswertung umdrehen kann.

[Temi00]

Zitat:

Zitat von MichaelT (Beitrag 1398251)

Der Fehler sofern dieser dort auftritt kommt aber genau von der Abwesenheit der Kurzschlussauswertung. Wenn der Autor sonst nichts angegriffen hat.

Ich hab jetzt in den Projekt Optionen einen Schalter gefunden "Complete Boolean Evaluation" Der war auf True. Komisch da im Internet steht default False;

Habe nun auf False gesetzt. make clean. Und nochmal mit debugger gestartet. Wieder die selbe Stelle. Das verstehe ich nun überhaupt nicht. Current ist ja nun defintiv nil und dann sollte der zweite Ausdruck ja nicht mehr geprüft werden.

habe dann kurz voher

{B-} eingefügt jetzt ist der Fehler an anderer Stelle
{B-} wieder entfernt Fehler bleibt an dieser anderen Stelle ???
Da ich ja den Source geändert habe dürfte ein make clean ja nicht nötig sein. Trotzdem clean aber der Fehler bleibt da (an dieser zweiten Stelle) Ich glaub ich schmeiss die Flinte ins Korn. Der externe soll nochmal ran. Ich brauch erst ein Kurs (Für Pascal und IDE)

Danke erst mal

[MichaelT]

Ich würde mal im Projekt die Einstellung auf False lassen. Die hast du vermutlich umgestellt.

Interessant bei mir reagiert der Compiler auf das Pragma nicht, auf die Project Settings schon. Ich bin unter Delphi 10.2 (pur).

Wir müssen die richtige Stelle finden an der dieser Fehler passiert. Also können wir nichts ausschließen. Schön wäre es gewesen.

Aus der Ferne kann ich nichts sagen und ich bin vermutlich ganz weit weg.

Frage: Wie weit weg von dieser Codestelle ist woanders?

Wenn dann müssten wir mit {B-} und {B+} den Bereich einschränken.

Aber zuvor gibt es noch die Einstellungen am Package selbst und nicht nur im Projekt. Aber plag ich nicht.

Zitat:

Zitat von Temi00 (Beitrag 1398301)

Zitat:

Zitat von MichaelT (Beitrag 1398251)

Der Fehler sofern dieser dort auftritt kommt aber genau von der Abwesenheit der Kurzschlussauswertung. Wenn der Autor sonst nichts angegriffen hat.

Ich hab jetzt in den Projekt Optionen einen Schalter gefunden "Complete Boolean Evaluation" Der war auf True. Komisch da im Internet steht default False;

Habe nun auf False gesetzt. make clean. Und nochmal mit debugger gestartet. Wieder die selbe Stelle. Das verstehe ich nun überhaupt nicht. Current ist ja nun defintiv nil und dann sollte der zweite Ausdruck ja nicht mehr geprüft werden.

habe dann kurz voher

{B-} eingefügt jetzt ist der Fehler an anderer Stelle
{B-} wieder entfernt Fehler bleibt an dieser anderen Stelle ???
Da ich ja den Source geändert habe dürfte ein make clean ja nicht nötig sein. Trotzdem clean aber der Fehler bleibt da (an dieser zweiten Stelle) Ich glaub ich schmeiss die Flinte ins Korn. Der externe soll nochmal ran. Ich brauch erst ein Kurs (Für Pascal und IDE)

Danke erst mal