Allermerkwürdigste Fehler........

[AHT]

So, jetzt habe ich die Faxen dicke und starte eine Umfrage!

Habe seit einigen Jahren (Profanversion ab 7.5 - 9.0, weiter habe ich nichts gekauft) das Problem, das merkwürdifge zeitweise Fehler auftreten, die eigentlich nur im Interpreter von Profan passieren können (ob der Grund dafür ein Fehler in meinen Quelltexten ist, lassen wir mal offen).

Dabei werden auf manchen Rechnern (abhängig von der Installation, nicht vom Betriebsystem) Zugriffsverletzungen erzeugt oder APIs nicht korrekt ausgeführt. Ob diese Fehler passieren oder nicht, hängt unter anderem davon ab, welche Quelltextpassagen vor dem Auftreten des Fehlers durchlaufen werden. Füge ich im Quelltext ein REM ein und erhöhe so die Zeilenzahl, läuft der Quelltext auf dem Rechner, der vorher den Fehler erzeugt hat, problemlos durch - dafür passiert dann der Fehler eventuell auf einem anderen Rechner mit dem gleichen Betriebsystem (hab bei mir einiges an Auswahl). Bei der Anwendung, die ich zur Zeit hier habe, passiert der Fehler eigentlich nur, wenn ich nicht vorher irgendwann einmal den Quelltext über den Editor aufgerufen habe. Habe ich das getan, kann ich das Programm starten und der Fehler passiert nicht. Ob der Fehler auch bei nicht compilierten Programmen auftritt kann ich nicht sagen - hatte das Problem bislang immer nur mit einer EXE.

Bislang waren die Quelltexte, bei denen das passierte, immer so um die 10000 Zeilen groß. Habe jetzt hier einen mit etwa 800 Zeilen - das ist ja schon ein Fortschritt.

Wem geht es ähnlich wie mir? Wer ist auf ähnliche Sachen gestoßen, die er sich zur Zeit einfach nicht erklären kann?
- Rechnerabhängig (nicht Betriebsystemabhängig)
- Geht weg, wenn man REMs einfügt
- Tritt mal auf, mal nicht (ohne etwas am Programm zu ändern)

[iF_]

In mir bekannten Fällen war immer unsachgemässe Nutzung die Ursache, z.B. wenn man ProcAddr zweckfremd anwendet oder Programmcode anderweitig "injiziert" z.B. auch über zusätzliche eigene Threads.

Das solche "Fehler" "mal" und "mal nicht" auftreten ist auch leicht vorstellbar wenn man versucht sich in die Zeitscheiben zwischen Prozess<>Prozess<>Thread1..x einzudenken und sozusagen nicht nur mit dem eigenen Programm gedanklich "mitläuft" - und kein System gleicht dem anderen.

[Frabbing]

Wem geht es ähnlich wie mir? Wer ist auf ähnliche Sachen gestoßen, die er sich zur Zeit einfach nicht erklären kann?
- Rechnerabhängig (nicht Betriebsystemabhängig)
- Geht weg, wenn man REMs einfügt
- Tritt mal auf, mal nicht (ohne etwas am Programm zu ändern)

Kommt mir bekannt vor, das mit den REMs. Es handelte sich hierbei um einen Bug, den Roland mit Version 10 - glaube ich! - beseitigt hat. Danach ist der Fehler bei mir nie wieder aufgetreten.
Hatte auch nichts mit ProcAddr, Prozessen oder Threads zu tun, sondern lag an XProfan. Das was du meinst, iF, produziert bei mir die aberwitzigsten Fehlermeldungen, aber eher keine Abstürze.

[MaZz]

Nach meinen Erfahrungen kann ich mich nur IF anschließen. In den seltenen Fällen, wo solche Probleme auftraten, waren sie "quelltextbedingt" (ohne mich jetzt an die Einzelheiten zu erinnern).
Etwas seltsam ist allerdings bei Dir die fehlerfreie Funktion nach einem Aufruf im Editor, falls damit das bloße Betrachten des Codes gemeint ist, so wie ich das herauslese. Das würde ja bedeuten, daß die EXE sich irgendwie des Codes bedient, der durch den Editor in den Speicher gelangt ist... Wenn ich das nicht gänzlich falsch verstanden habe.

[iF_]

Nachtrag: @AHT: Das "Rem"-Phänomen (wir "reden" hier imho nicht von bekannten und behobenen XProfan-Bugs) hat imho eigentlich mit dem REM selbst nichts zu tun, könnte auch AddString-Phänomen oder Print-Phänomen genannt werden.

Das "Phänomen" zeigt auch nur, dass durch versetzen von Codezeilen "injezierter" Code "zufälligerweise" __anders "crasht" - also ein "Pseudophänomen".

So gesehen gibt es keine "unerklärlichen" Abstürze.

[AHT]

Zitat von iF_

In mir bekannten Fällen war immer unsachgemässe Nutzung die Ursache, z.B. wenn man ProcAddr zweckfremd anwendet oder Programmcode anderweitig "injiziert" z.B. auch über zusätzliche eigene Threads.

Ist bei dem ersten Programm, bei dem ich diese Probleme hatte, nicht der Fall gewesen. Die Profanversion kannte ProcAddr noch gar nicht . Bei dem 800 Zeilen Programm verwende ich ProcAddr gar nicht.

Zitat von iF_

Das solche "Fehler" "mal" und "mal nicht" auftreten ist auch leicht vorstellbar wenn man versucht sich in die Zeitscheiben zwischen Prozess<>Prozess<>Thread1..x einzudenken und sozusagen nicht nur mit dem Programm gedanklich "mitläuft" - und kein System gleicht dem anderen.

Dann versuche dich da mal einzudenken:

a) Programm 1 erzeugt bei jedem Start eine Zugriffsverletzung. Führe ich Programm 1 im Profaneditor aus, erscheint die Zugriffsverletzung nicht (erklärlich). Starte ich dann Programm 1 erneut als EXE, kommt die Zugriffsverletung so lange nicht mehr, bis ich neu gebootet habe.
Bin auf deine Theorie gespannt.
b) Erkläre mir bitte mal folgende Windows Fehlermeldung (steht genau so da): Die Anweisung in Adresse "0x00000000" verweist auf Speicher in "0x00000000". Der Vorgang "read" konnte nicht auf dem Speicher durchgeführt werden.

Die Anweisung in Adresse "0x00000000" dürfte ja bedeuten, dass das Register EIP den Wet 0 enthält. Da mein Programm erst ab %Hinstance im virtuellen Speicher beginnt (4194304 dezimal), kann das ja eigentlich nur durch einen fehlerhaften Call entstehen. Einen Call führe ich in meinem Quelltext aber nicht durch. Füge ich ein REM ein, läuft alles wunderbar.
Ich habe jetzt noch nicht nachgeprüft, auf welcher Adresse sich die Register dieses Threads befinden und ob man die zum Beispiel durch fehlerhaft dimensionierte Variablen einfach überschreiben kann - ich denke aber, das geht nicht (Wahrscheinlichkeit geht gegen 0). Wahrscheinlicher wäre da, dass irgendein Vorgang Profaninterne Variablen des Interpreters überschreibt, die dann einen fehlerhaften Call auslösen. Werde mal schauen, ob man das irgendwie eingrenzen kann - sind ja nur 800 Zeilen.

[AHT]

Zitat von Frabbing

Kommt mir bekannt vor, das mit den REMs. Es handelte sich hierbei um einen Bug, den Roland mit Version 10 - glaube ich! - beseitigt hat. Danach ist der Fehler bei mir nie wieder aufgetreten.
Hatte auch nichts mit ProcAddr, Prozessen oder Threads zu tun, sondern lag an XProfan. Das was du meinst, iF, produziert bei mir die aberwitzigsten Fehlermeldungen, aber eher keine Abstürze.

Das hört sich gut an. Roland, was war da los? Was wurde geändert? Könnte meine Probleme erklären...

[AHT]

Zitat von MaZz

Wenn ich das nicht gänzlich falsch verstanden habe.

Fast richtig verstanden! Habe den Code dort ausgeführt und nachher die EXE gestartet, den Code also nicht nur "betrachtet".

Zitat von MaZz

Das würde ja bedeuten, daß die EXE sich irgendwie des Codes bedient, der durch den Editor in den Speicher gelangt ist...

Nein, wohl eher nicht. Kann andere Ursachen haben.

[AHT]

Zitat von iF_

Nachtrag: @AHT: Das "Rem"-Phänomen (wir "reden" hier imho nicht von bekannten und behobenen XProfan-Bugs) hat imho eigentlich mit dem REM selbst nichts zu tun,

Das ist klar - wem erklärst du das? Wenn es um virtuellen Speicher geht, habe ich wohl etwas mehr praktische Erfahrung als du .

Zitat von iF_

Das "Phänomen" zeigt auch nur, dass durch versetzen von Codezeilen "injezierter" Code "zufälligerweise" __anders "crasht" - also ein "Pseudophänomen".

Was ist für dich "injizierter" Code? Mein Code ruft keine Callbacks auf und nutzt keine weiteren DLLs, INCs oder PCUs.
Vielleicht ist "Code" durch einen Variablenüberlauf injiziert - meinst du das vielleicht? Ist immerhin möglich, keiner ist fehlerfrei.
Da ich aber besonders viele Rechner besitze könnte ja immerhin sein, das mir etws auffällt, was anderen vielleicht nicht auffällt, weil sie nur eine Maschine zum Testen haben und sich Tester, bei denen sich ein Programm mit Zugriffsverletzung verabschiedet, in Regel nicht beim Autor melden, sondern nur das Proggie einfach nur genervt vom Rechner löschen.

[iF_]

Erkläre mir bitte mal folgende Windows Fehlermeldung (steht genau so da): Die Anweisung in Adresse "0x00000000" verweist auf Speicher in "0x00000000". Der Vorgang "read" konnte nicht auf dem Speicher durchgeführt werden.

Diese Meldung kann man mit einer Programmzeile erzeugen, aber reden wir von einem bestimmten Code oder geht es um ein bestimmtes Verständnis?

Oder anders: Hast Du ein konkretes Ziel?

[RGH]

Zitat von AHT

Das hört sich gut an. Roland, was war da los? Was wurde geändert? Könnte meine Probleme erklären...

Seit Deiner Version 9 wurden einige solcher schwer eingrenzbarer Probleme dingefest gemacht und dann natürlich auch gefixt.

Bei derart mysteriösen Problemen ist immer das größte Problem, einen kleinen Quellcode zu finden, der den Fehler nachvollziehbar auslöst.

In den meisten Fällen handelt es sich letztendlich um kleinste nicht erlaubte Speicherzugriffe. So etwas kann sehr oft gut gehen, wenn auf ein Byte zugegriffen wird, dass nicht weiter benutzt wird, manchmal aber eben nicht, wenn das Byte anderweitig benutzt wird oder das auslesen ein unerwartetes Ergebnis zeitigt. Und da dann z.B. ein verändern des Quellcodes - auch durch REMs - Veränderungen im Speicher des Rechners verursacht, kann das z.B. zu verändertem Verhalten führen.

So etwas kann bei nicht ganz korrekt abgehandelten Syntaxfehlern vorkommen. Klar sollte der Parser so etwas mit einer ordentlichen Fehlermeldung beantworten, aber manchmal macht es eben nicht. (Natürlich reduziere ichdie Situationen, wo dies passieren kann von Version zu Version. Aber es ist leider ziemlich unmöglich, alle denkbaren Syntaxfehler in Testcodes einzubauen, um diese Geschichte sicher zu testen.)

So etwas kann auch vorkommen, wenn man z.B. irgendwo einen Bereich um ein oder wenige Bytes zu klein dimensioniert, oder Bereiche, die an APIs übergeben werden auch zu groß. Gerne vergißt man mal beim Bereich für einen String, dass da auch das abschließende Null-Byte Platz benötigt. Gerade bei API-Aufrufen kann so etwas gerne passieren.

In früheren Versionen gab es auch mal diesbezügliche sehr seltene Probleme bei LoadFile$() und SaveFile$(), die insbesondere dann aufgetreten sind, wenn die EXE komprimiert wurde. Hier sich unter einer neueren Windowsversion eine API-Struktur um einige Bytes vergrößert und als ich dann eine Delphi-Version nutzte, die diese größere Struktur verwendetete, knallte es bei manchmal älteren Windowsversionen. Das ist behoben. Dann gab es auch noch einen Fehler in einer Delphi-Version bei Nullterminierten Strings der Länge 0. Das musste ich dann umgehen. Das führte zu gelegtlichen Abstürzen bei den Richtext-Funktionen. AUch der Fehler wurde schließlich eingekreist, entlarvt und behoben.

Gruß
Roland

[RGH]

Zitat von AHT

Erkläre mir bitte mal folgende Windows Fehlermeldung (steht genau so da): Die Anweisung in Adresse "0x00000000" verweist auf Speicher in "0x00000000". Der Vorgang "read" konnte nicht auf dem Speicher durchgeführt werden.

Die Fehlermeldung kann man sehr leicht produzieren, wenn man z.B. an eine API-Funktion, die eine Adresse erwartet, eine 0 übergibt. Und wenn man dann noch eine 0 dahin schreiben will ...

So etwas kann ein Fehler im Programm sein. Etwa eine nicht initialisierte Variable, die man an eine API-Funktion übergibt oder wenn man z.B. ein Handle ermittelt, aber nicht überprüft, ob nicht ein Fehler aufgetreten ist (was zur 0 führt) und das vermeintliche Handle bei einer weiteren API-Funktion verwendet ...

oder ...

Es gibt da viele Möglichkeiten! Eine Nullpointer-Exception ist wahrlich kein seltenes Sammlerstück unter Programmierern!

Gruß
Roland

[Frabbing]

Andreas, benutzt du Programmzeilen, die über mehrere Zeilen gehen? Messagebox usw. Das ist auch so eine Situation, an die ich mich erinnern kann, nachdem der Fehler weg war, als ich die mehreren Zeilen in nur eine Zeile geschrieben hatte...

[AHT]

Zitat von RGH

Es gibt da viele Möglichkeiten! Eine Nullpointer-Exception ist wahrlich kein seltenes Sammlerstück unter Programmierern!

Das hier zweimal null steht ist dir aufgefallen? Damit die erste 0 kommt, müsste ich ja erst einmal auf Adresse 0 springen, und das tue ich in meinem Quelltext gar nicht - dort wird definitiv von mir kein Call ausgeführt. So wie ich das sehe wird von mir dort auch keine API aufgerufen, durch deren Parameter sich ein Nullcall ergeben könnte. Desweiteren ist der Nullcall weg, wenn ich ein REM in meinen Code einfüge. Wie genau kann dann ein solcher Nullcall entstehen? Eher durch einen Befehl in meinem Profancode oder durch einen Befehl in deinem Delphicode???

Zitat von Frabbing

Andreas, benutzt du Programmzeilen, die über mehrere Zeilen gehen? Messagebox usw. Das ist auch so eine Situation, an die ich mich erinnern kann, nachdem der Fehler weg war, als ich die mehreren Zeilen in nur eine Zeile geschrieben hatte...

Nein, aber ich denke, wir reden vom selben Problem. Laut Roland wurde da wirklich was gefixt - ich schaue da also erst einmal nicht weiter. gib mir aber bitte mal Rückmeldung, wenn solche Fehler bei dir wieder auftauchen sollten.
Sollten du ein Posting finden, das sich auf diesen Fix bezieht, gib mir bitte den Link. Ich werde dann überprüfen, ob das was da gefixt wurde zu meinen Problemen passt.

[AHT]

Zitat von iF_

Diese Meldung kann man mit einer Programmzeile erzeugen, aber reden wir von einem bestimmten Code oder geht es um ein bestimmtes Verständnis?

Oder anders: Hast Du ein konkretes Ziel?

Es ging mir nur darum, ob du verstanden hast, was diese Zeilen bedeuten, nämlich:

Call(0,0)

Ich denke, das ist verständlich.
Wenn ich nicht "calle", kann der, der einen Call ausführt, nur der Delphiquelltext von Profan sein.