Test Sim 3.4.1.1

[Thomas U.]

O.K. In meiner Naivität hätte ich dann etwas wie "now()" erwartet...

Delphi ist da etwas anders. Funktionen ohne Parameter brauchen/haben keine Klammern.

War meine größte Fehlerquelle am Berufskolleg bei der Programmierung mit C(++) statt dem sonst genutzten Delphi... die zweite war ":=", "==" und "="

[Alwin Meschede]

Hmm. Aber diese Diskrepanz bei "now" ist mMn entweder ein Fehler in der Speicherverwaltung oder ein Hardwareproblem des RAM.

Nee. In dem Stackoverflow-Thread steht ja, was da los ist: DirectX stellt beim Erzeugen des Device die FPU auf single precision um. Wenn man dann in diesem Modus auf einem TDateTime (double precision) rumrechnet, geht dort Genauigkeit verloren. Das sind die ominösen 3 Minuten. Man kann jetzt dieses Flag D3DCREATE_FPU_PRESERVE setzen, um das zu umschiffen. Für den Alltagsbetrieb ist das aber nicht empfehlenswert, weil die ganze DX-Pipeline dann mit doppelter Genauigkeit laufen muss.

[Christian Sch.]

Hmm. Aber diese Diskrepanz bei "now" ist mMn entweder ein Fehler in der Speicherverwaltung oder ein Hardwareproblem des RAM.

Nee. In dem Stackoverflow-Thread steht ja, was da los ist: DirectX stellt beim Erzeugen des Device die FPU auf single precision um. Wenn man dann in diesem Modus auf einem TDateTime (double precision) rumrechnet, geht dort Genauigkeit verloren. Das sind die ominösen 3 Minuten. Man kann jetzt dieses Flag D3DCREATE_FPU_PRESERVE setzen, um das zu umschiffen. Für den Alltagsbetrieb ist das aber nicht empfehlenswert, weil die ganze DX-Pipeline dann mit doppelter Genauigkeit laufen muss.

Ja das hatte ich dann auch gelesen...

Ich hoffe die Person, der das eingefallen ist, wurde ausreichend mit Lob bedacht... Aber halt. Bevor ich jemanden verdächtige: könnten ja auch Sachzwänge aus der Evolution von Windows und/oder DirectX sein...

[Carsten Hölscher]

Jau, den Effekt kenn ich schon lange und setze das darum nach dem Create wieder zurück. Hatte nicht auf dem Schirm, dass now direkt nach dem Createdevice dadurch beeinflusst werden könnte.
danke, auch wenn's der eigentlichen Lösung dann wohl nicht dienlich ist.

Carsten

[Max Senft]

Ahoi in die Runde. Nochmal OT:

Arbeiten denn moderne DirectX Versionen/Grafikkarten immer noch mit Single Precision Berechnungen? Hätte ja vermutet, dass in der aktuellen 64 Bit Welt dann auch dort mit 64 Bit, also Double Precision, gerechnet wird?

Grüße
Max

[Carsten Hölscher]

Bitte testet mal die aktuelle Beta und gebt Rückmeldung.

Carsten

[dk48]

Hallo,
vorab Danke für die Gute Arbeit, Version 3.4.1.5 hängt nicht mehr - bricht nur noch ab... was aber ok ist.

Habe heute wie folgt gestestet, reproduzierbarer Fehler mit Version 3.4.1.1:
- Fahrplan gestartet und einen Zug bis zum Ende fahren lassen ... ohne Bewertungsfenster
- Mit Fahrplan neu starten einen zweiten Zug bis zum Ende fahren lassen ... mit Bewertungsfenster
- Mit Fahrplan neu starten einen dritten Zug gestartet ---> ZUGRIFFSVERLETZUNG bei Adresse aaaa .... Lesen von Adresse bbbb
- OK gedrückt und mit "X" oben rechts Programm versucht zu beenden ---> ZUGRIFFSVERLETZUNG bei Adresse cccc .... Lesen von Adresse dddd
- OK gedrückt -> Programm hängt in einer Endlosschleife
- Mit Taskmanager beendet.

Zweiter Test reproduzierbar mit Version 3.4.1.5
- Fahrplan gestartet und einen Zug bis zum Ende fahren lassen ... mit Bewertungsfenster
- Mit Fahrplan neu starten der zweiten Zug gestartet ---> ZUGRIFFSVERLETZUNG bei Adresse eeee .... Lesen von Adresse ffff
- OK gedrückt ---> Program wird sofort beendet und kann neu gestartet werden.

Dritter Test mit Version 3.4.1.5
- Fahrplan gestartet und einen Zug bis kurz vor dem Ende fahren lassen ... ohne Bewertungsfenster
- Mit Fahrplan neu starten der zweiten Zug gestartet ---> Fehler bei der Bereichsprüfung
- OK gedrückt ---> Program wird sofort beendet und kann neu gestartet werden.

Vielleicht hilft diese Info weiter - aber mit dieser Reaktion des Programm kann man gut leben
Danke für die Mühen aller Beteiligten
Dieter

[Carsten Hölscher]

Es geht eigentlich vor allemum die Frage, ob die Fahrpläne jetzt wieder zuverlässig starten. Da wäre jede Meldung willkommen, auch positive.

Am Umgang mit Exceptions dürfte nichts geändert sein.

Carsten

[Thomas U.]

Bitte testet mal die aktuelle Beta und gebt Rückmeldung.

Der Fehler beim Laden kommt weiterhin, wie gehabt mal ja, mal nein und mit höherer Zuverlässigkeit bei großen Plänen/Strecken. Bspw. der schon letztens zum Entgleisungstest genutzte ICE 578 aus dem Plan Göttingen_Kassel_2017. Im vollen Plan endet das Laden mit dem bekannten Fehler, mein abgeänderter Testplan, der nur diesen einen Zug enthält, lädt tadellos.

Neu ist, dass beim Erscheinen des Fehlers das Meldungsfenster aufplöppt und mehrfach (recht zuverlässig 8x) "BeginScene fehlgeschlagen (D3DERR_INVALIDCALL)" auswirft. Das Wegklicken der Fehlermeldung schließt Zusi nun direkt, der Griff zum Taskmanager ist nicht mehr nötig.

[M.C.S.]

Hallo,

ich wollte heute mal das Abenteuer Beta-Version wagen, hätte aber vorher schauen sollen, ob es Probleme gibt (clever clever *uhm*). Na egal, ich versuche dann mal zu helfen

ZusiSim.exe : 3.4.1.5

Ich habe nach jedem Versuch das Programm neu gestartet, also auch wenn die Fahrt erfolgreich war.

Fahrplan: Lehrte-Maschen 2017 (04-14 Uhr)

1. MEr 81605_81608 RB 31 Hamburg Hbf - Lüneburg - Hamburg Hbf
2. Fehler beim 1. Versuch: Zugriffsverletzung bei Adresse 005629CA beim Lesen von Adresse 00000000
3. Fehler beim 2. Versuch: Zugriffsverletzung bei Adresse 005629CA beim Lesen von Adresse 00000000
4. Fehler beim 3. Versuch: Zugriffsverletzung bei Adresse 005629CA beim Lesen von Adresse 00000000

Fahrplan: Lehrte-Uelzen (20.06.2018 von 13 Uhr bis 22 Uhr)

1. ME 82819 Uelzen - Göttingen
2. Erfolg beim 1. Versuch: Strecke komplett durchgefahren (ich bin nicht mehr 100% sicher, ob es der 82819 oder 82821 war, aber auch der 82821 lieferte danach denselben Fehler)
3. Fehler beim 2. Versuch: Zugriffsverletzung bei Adresse 005629CA beim Lesen von Adresse 00000000
4. Fehler beim 3. Versuch: Zugriffsverletzung bei Adresse 005629CA beim Lesen von Adresse 00000000

Ich wüsste ja gerne, warum es 1x geklappt hat mit der zweiten Strecke, aber keine Ahnung. Ich boote mal Windows jetzt neu und versuche es dann nochmal.

Ich habe außerdem vom hängenden Zusi.exe-Prozess eine Abbilddatei erstellt, weiß aber nicht, womit ich die gescheit öffnen kann. Das Tool "BlueScreenView" zeigt jedenfalls nichts an und der Dump ist ca 640 MB groß. Ich versuch es sonst später mal mit VisualStudio Community...

Nachtrag 1:
Rechner neu gestartet und dann immer auf Sekunde 0 ZUSI gestartet und möglichst schnell zum Fahrplan und Zug geklickt.

1. Rechnerneustart
2. Zusistart, Lehrte-Uelzen, 80819, bis zum Punkt wo Exception kam: 79 Sekunden seit Programmstart, klappt
3. Zusistart, Lehrte-Uelzen, 80819, bis zum Punkt wo Exception kam: 78 Sekunden seit Programmstart, klappt
4. Zusistart, Lehrte-Maschen, 81673 (daneben geklickt, sollte 81605 werden), bis zum Punkt wo Exception kam: 70 Sekunden seit Programmstart, Fehler: 005629CA
5. Zusistart, Lehrte-Uelzen, 80819, bis zum Punkt wo Exception kam: 78 Sekunden seit Programmstart, Fehler: 005629CA
6. Zusistart, Lehrte-Uelzen, 80819, Fahrplananzeige geladen nach 35 Sekunden, bis zum Punkt wo Exception kam: 78 Sekunden seit Programmstart, Fehler: 005629CA
7. Rechnerneustart
8. Zusistart, Lehrte-Maschen, 81605, bis zum Punkt wo Exception kam: 80 Sekunden seit Programmstart, klappt (Premiere!!!), Strecke durchgefahren
9. Zusistart, Lehrte-Maschen, 81605, bis zum Punkt wo Exception kam: 78 Sekunden seit Programmstart, klappt, direkt beendet vorm Aufgleisen
10. Zusistart, Lehrte-Maschen, 81605, bis zum Punkt wo Exception kam: ?? Sekunden seit Programmstart, klappt, direkt beendet vorm Aufgleisen
11. Zusistart, 1 Min warten bis Fahrplanauswahl Lehrte-Maschen, 2 Min warten bis Auswahl 81673, Fehler: 005629CA

Damit höre ich erstmal auf - keine Ahnung, was ich weiter testen kann. Evtl 3x Rechner neu starten und gaaaaaanz langsam bis zum ZUSI-Start klicken? Das würde ich aber nur machen, wenn explizit gewünscht

Nachtrag 2:
Das Problem ist echt flutschig. Ohne zu wissen, ob das überhaupt weiterhilft, habe ich nach Zusi-Start an den Prozess mal in Visual Studio (Community) einen Debugger attached (wo ich aber nix sehen kann außer dem aktuellen Speicherverbrauch). Gefühlt (nach mehreren Versuchen) steigt damit die Wahrscheinlichkeit drastisch auf mindestens 80%, dass ich es ohne Zugriffsfehler in die Simulation schaffe. Warum - keine Ahnung

[Michael Springer]

Bei mir bringt die V3.4.1.5 keine wesentliche Verbesserung. Mit meinem Testzug

_ZusiData\Timetables\Deutschland\Paderborn_Kassel\Fiktives_S-Bahn-Netz_1998_04-14Uhr\Fiktives_S-Bahn-Netz_1998_04-14Uhr.fpn -> S9004.trn

habe ich (zumindest hier auf diesem PC) eine hohe Chance den Absturz zu erleben. Einmal als ich den Zug nicht mit Doppelklicken, sondern mit Markieren und dem Start Button gestartet hatte, kam kein Absturz. Ich glaube, dass war aber Zufall. Bei einem weiteren Versuch stürtze er auch mit dieser Methode ab.

Ansonsten scheint wohl das BeginScene das Problem zu sein.



Nachtrag:
Ich habe von Programmieren keine Ahnung, aber ich rate mal ins Blaue... bei MS steht, wenn man danach googelt:
D3DERR_INVALIDCALL - The method call is invalid. For example, a method's parameter may not be a valid pointer.
Könnte es vielleicht sein, dass auf manchen Rechnern die Reihenfolge der Fenster zufällig ist? Also das versucht wird zuerst ein Zusi-Display Fenster aufzurufen, obwohl das Hauptfenster noch nicht da ist? Und deswegen vielleicht der Pointer noch leer ist?

[Carsten Hölscher]

Danke Euch. Es scheitert das Initialisieren des "DX-Device", quasi der grundlegende Zugrif auf die Grafikkarte. BeginScene geht als Folge davon dann auch nicht. Sehr seltsam ist das Zufällige daran. Werde dann mal weiter suchen müssen.

Carsten

[Michael Springer]

Also ich habe ein GTX1050 und so eben mal meinen Grafiktreiber aktualisiert. Ergebnis: Wie vorher. Keine Veränderung.

Also orakle ich mal weiter: Initialisieren des "DX-Device" ist doch geht oder geht nicht. Also schwarz/weiß. Vielleicht oder halb gibts da nicht. Warum gehen kleinere Fahrpläne problemlos und größere Fahrpläne nicht? Wenn es schwarz/weiß ist, müsste es ja immer gehen oder nicht gehen.
Das bringt mich auf die Idee einer zeitlichen Komponente. Stehen bei den Kleineren vielleicht die Ressourcen schneller zur Verfügung und deshalb klappt der Aufruf? Und bei den Größeren rechnet noch irgendwas und der Aufruf kommt irgendwie zu früh, bevor alle Ressourcen parat stehen?

Gerade mal im Raum Kassel bei 3-4 Modulen die Mutter.ls3 umbenannt. Auch keine Änderung.

[Carsten Hölscher]

Tja, das Rätsel ist wirklich rätselhaft. Ich hab bisher auch keine Idee und dummerweise läuft die letzte Version auf meinen PCs, habe also nicht mal einen Testfall.

Carsten

[M.C.S.]

Ich habe jetzt 19x Zusi gestartet, mal mit, mal ohne Prozess-Debugger von VS 2019.

Deutliches und eigentlich nicht mehr durch Varianz erklärbares Ergebnis:

1. 3x erfolgreich ohne Debugger
2. 7x fehlerhaft ohne Debugger
3. 9x erfolgreich mit Debugger
4. 0x fehlerhaft mit Debugger

Wenn man bedenkt, dass ich das Gefühl auch schon am Vortag hatte, wo ich das aber noch nicht systematisch protokolliert hatte, kann man wohl sagen, dass der VS-Debugger irgendwas zum Besseren bewirkt. Ich kenne den Debugger allerdings überhaupt nicht, vermute daher eher sowas wie "Der bremst / linearisiert ein wenig die Programmverarbeitung und deshalb tritt eine mögliche Race-Condition viel seltener auf" (am Vortag hatte ich nämlich 1x einen Fehlschlag mit aktiviertem Debugger - komplett lösen tut der das Problem also nicht).

Ich hab das Prozedere mal um Ladezeiten gekürzt als Video hochgeladen, um das methodische Vorgehen zu dokumentieren. Immer derselbe Fahrplan, immer dieselbe Zugnummer. Erst ein paar Mal mit und ohne Debugger im Wechsel, am Ende dann mehrfach ohne und dann mehrfach mit Debugger.

Vielleicht hilft es ja weiter.

[F. Schn.]

@Carsten: Um welche Funktion geht es? "CreateDevice"? Liefert diese Methode nicht ein HRESULT, und könntest du dieses HRESULT nicht mal im 1. Schritt ausgeben?

[Carsten Hölscher]

Die Results sind alle OK, sonst käme ne Meldung. Der Fall auf meinem PC wurde ausgelöst durch eine Message WM_Size (SIZE_RESTORED), die offenbar sinnlos beim Laden kam. Zusi führt dann ein Reset des DX durch und das schlug fehl, warum auch immer. Bei den korrekt ladenden Plänen unterblieb die Message WM_Size.
Ich werde morgen mal die letzte Änderung rückgängig machen und schauen, ob dann wieder alles geht. Dann ist zumindest klar, dass nicht irgendwas Drittes reinpfuscht.

Carsten

[Wolfgang Hüttner]

Wenn man bedenkt, dass ich das Gefühl auch schon am Vortag hatte, wo ich das aber noch nicht systematisch protokolliert hatte, kann man wohl sagen, dass der VS-Debugger irgendwas zum Besseren bewirkt

Bei der Debug - Version von Visual Studio werden andere, spezielle .dll - verwendet, die in VS das debuggen ermöglichen. Da diese auf jeden Fall zusätzlichen Code für das Debugging enthalten haben die sicherlich auch ein anderes Zeitverhalten.
Dass das Problem in irgendeiner Form ein zeitliches ist, hat ja auch schon Michael Springer vermutet. Das würde diesen Verdacht zumindest erhärten.

Gruß
Wolfgang

[Michael Springer]

Ich habe eine alte Gurke, einen Aspire One 756 mit Pentium 987 und interner Intel HDxxxx Graka, den habe ich gerade mal auf die V3.4.1.5 gepatcht und meinen Fahrplan mit der S9004.trn geladen. Beim 1. Versuch war alles ok, beim 2. Versuch kam der übliche Crash mit gleicher Speicheradresse. (Mehr Versuche hat es nicht gereicht, der lädt 15 Minuten pro Versuch *hihi*)

[Carsten Hölscher]

Mit Version 3.4.1.6 hab ich eine Meldung eingebaut, die das Ereignis WM_SIZE loggt. Sie erscheint beim Start und bei mir ist es so, dass Zusi abstürzt, wenn Sie nach dem Laden noch einmal kommt (auch ohne dass man das Fenster irgendwie "anfasst"). Kommt sie nicht, startet Zusi normal.
Alle, die einen Absturz erzeugen können, mögen bitte mal schauen, ob es sich bei ihnen auch so verhält.

Carsten