Mir ist das Programm heute beim Zeichnen abgestürzt. Mehrfach zwischen Zeichnungen umgeschaltet habe ich nicht.
Ich weiß noch nicht, wie das passieren konnte, habe aber einen Verdacht. Ich werde bei Gelegenheit versuchen, den Absturz zu reproduzieren, dann melde ich mich wieder.

Ich konnte meinen Absturz reproduzieren. Es hängt mit der Anzeige der Messlinien zusammen (Zeichnungen - Messlinien - Anzeigen) (Shortcut mit der Taste L). Wenn hier zu oft umgeschaltet wird, stürzt das Programm ab. Das passierte in einem Test nach über 100-mal umschalten. Vermutlich steckt dahinter derselbe Fehler wie bei dem Programmabsturz durch Umschalten zwischen verschiedenen Zeichnungen.

Das hat mich neugierig gemacht. Was wenn auch andere Funktionen zu einem Programmabsturz führen?

Und tatsächlich, auch beim häufigen Umschalten des Rasters (Shortcut Taste G) stürzt das Programm ab.
Das gleiche beim Wechseln des Maßstabes.
Das gleiche beim Anzeigen von Skizzen (Shortcut Taste K).

Da habe ich mit dem Testen aufgehört. Wer weiß, was alles noch einen Programmabsturz bewirken kann. Das Problem ist nicht nur eine Funktion oder zwei (Messlinien oder Umschalten von Zeichnungen), es ist viel größer.

Dazu kommt, dass sich die Fehler dieser verschiedenen Funktionen aufaddieren. Das erklärt auch, warum das Programm beim Zeichnen abstürzt, wenn man doch meinen könnte, so oft schaltet niemand zwischen Zeichnungen um.

Bitte schau dir das nochmal an.

Ich hab mir nochmal Zeit für dieses Problem genommen und konnte einige neue Erkenntnisse gewinnen. Ich hab mir dazu den Task Manager vor und während des Absturzes angeschaut.

Bei der Benutzung der benannten Funktionen steigt der Arbeitsspeicherverbrauch der Datei javaw.exe kontinuierlich.
Beim Umschalten zwischen Höhlen passiert dies ebenfalls, allerdings wird irgendwann eine Schwelle erreicht, zum Beispiel 800.000k. Sobald 50.000k mehr erreicht wird, also 850.000k, setzt ein Reset ein, der den Wert wieder auf 800.000k bringt. Somit wird 850.000k nie überschritten. Es kommt auch nie zu einem Absturz. (Die exakten Zahlen sind je Zeichnung unterschiedlich, also nicht immer bei 800.000K.)

Dieser Reset fehlt allerdings bei den oben genannten Funktionen (Raster, Umschalten von Zeichnungen, Maßstab, Messlinien etc.). Der Arbeitsspeicherverbrauch geht auch über den Schwellenwert von 850.000k immer weiter nach oben, bis der Absturz eintritt. Der Absturz geht ebenfalls mit einem Reset einher, offenbar wird der Wert halbiert. Bei mir von 1.050.000K auf ~500.000K. Wird hier womöglich zu viel aus dem Arbeitsspeicher gelöscht? 500.000K statt 50.000K. Eine Null zu viel?

Ganz so einfach ist es aber nicht. Es gibt auch Zeichnungen, bei denen Kein Absturz eintritt. Auch innerhalb der gleichen Datei.
Man kann auch beides abwechselnd benutzen um den Arbeitsspeicherverbrauch unnatürlich zu erhöhen. Ich konnte 1.900.000K erreichen. Könnte es sein, dass der geplante Reset bei bestimmten Zeichnungen irgendwie übergangen wird. z.B. wenn viele Befehle zu schnell hintereinander abgegeben werden? Oder könnte es vielleicht sein, dass der Reset in eine Art Warteschlange mit anderen Befehlen eingereiht wird, sodass er sein timing verpasst und zwar ausgeführt wird, aber zu einem Zeitpunkt wo die definierte Schwelle bereits so weit überschritten ist, dass auch nach dem Löschen von 50.000K ein Wert über der Schwelle erreicht wird und somit die Schwelle nicht mehr ausgelöst wird?

Vielleicht liegt das Problem auch woanders. Ich frage mich vor allem, warum der Reset bei manchen Zeichnungen auftritt, bei anderen aber nicht. Kleine oder leere Zeichnungen scheinen irgendwie anfälliger zu sein. Hängt der Reset von der Größe der aktuell geöffneten Teildatei (Zeichnung+Messdaten) ab?

Das war jetzt viel Text aber ich hoffe, es war etwas Hilfreiches dabei.

I have not experienced crashes as such, but I have the felling the software is a lot more prone to weird behavior (e.g. drawing disappearing like they've been deleted) since one of the late version 6.x I would say (sorry can be more accurate). I do save and close and reopen a lot more than I used to do. This generally solves the issue... I haven't lost anything but I feel CRP is a lot more instable.

How exactly did drawings disappear for you? Is this the only reason you restart the program a lot nowadays or are there other similar problems?

I noticed that objects like lines for example disappear from the log when drawing and doing ctrl z or ctrl y quickly, which means I can't go back to certain drawing status anymore. Is this what you mean by drawings disappearing?
Or do whole cave maps disappear from your files?

What other weird behaviour have you noticed?

By the way, I have a list of problems that need to be addressed at some point, but I don't want to flood the forums even more than I do anyway.

Hi Andreas,
I haven't lost anything yet like you seem to experience.

Some times I "jump" from one menu tab to another and before coming back to the drawing tab and then it looks like a virgin/blank page. However, if I save and reopen the file, all drawings are back like nothing happened. I think it's more a graphical issue here, maybe due to memory overload.

I don't have a list of the weird behaviour yet, it's more like a feeling at the moment, thing are lessflaw less than before... sorry not to be able to be more specific here.

@ Jochen
Es tut mir echt Leid, aber irgendwie stürzt das Programm wieder unverändert ab. Heute Mittag mit der Demo hat alles noch super ausgeschaut. Ich kann mir das nicht erklären, das deprimiert mich grad alles.

@Thomas
If I accidentally hover over the menu bar while trying to zoom in or out of a drawing I also "jump" to a different tab, which is annoying. But this does not lead to my drawing being blank when I return.
I still think the mouse wheel should not change tabs on the menu bar though.

Jochen und ich haben uns in den vergangenen Tagen intensiv mit dem Thema befasst und versucht, eine Lösung zu finden.

Es ist klar geworden, dass der Programmabsturz das Symptom eines Fehlers ist, über den wir weiterhin wenig wissen. Allerdings ist es uns gelungen, einen Workaround zu finden, damit der Absturz praktisch nicht mehr auftritt.
Mit dem Release 7.3.0 wurden dahingehend ein paar Änderungen vorgenommen.

Zunächst wurde das Maximum des GPU/VRAM Speichers auf 2GB erhöht. Target VRAM liegt nun bei 1 GB (der Hälfte von maxVRAM).
Max. CPU/Heap wurde ebenfalls auf 2GB festgelegt. Target Heap dementsprechend bei der Hälfte, also 1 GB.
Zusätzlich wurde V-Sync deaktiviert. Der Unterschied in der Bildqualität sollte kaum merkbar sein. Allerdings läuft CaveRenderPro ohne V-Sync nun deutlich stabiler.

Nach diesen Änderungen lässt sich der Programmabsturz nur noch mit 'Gewalt' herbeiführen. Im normalen Gebrauch ist ein erneutes Auftreten praktisch ausgeschlossen.

Allerdings könnte es sein, das mit den neuen Einstellungen auch neue Probleme auftreten. Sollten einem anderen User also nach Release 7.3.0 neue Probleme / Programmfehler / Abstürze / schlechtere Performance oder andere ungewöhnliche Verhaltensweisen auffallen, bitte ich darum, im Forum darüber zu berichten. Wir gehen nicht davon aus, dass es zu solchen Problemen kommt. Uns sind beim Testen keine begegnet, aber mit Sicherheit kann man das noch nicht sagen.

Sollte es dennoch zu Problemen kommen, besteht die Möglichkeit, dass Änderungen wieder rückgängig gemacht werden.

Der User hat jetzt außerdem die Möglichkeit, sollten neue Stabilitäts-Probleme auftreten, diese möglicherweise selbst zu beheben, ohne auf einen neuen Release warten zu müssen.
Dazu kann die neue batch-Datei 'CaveRenderPro.bat' verwendet werden. Diese befindet sich im Installationsordner und kann mit 'rechter Maustaste --> bearbeiten' geöffnet werden.

Hier kann man die Werte für VRAM, Heap und V-Sync ändern.
Das Hinzufügen des Befehles '-Dprism.order=sw' z.B. erhöht die Stabilität, allerdings funktioniert 'Grafik - Volumen' dann nicht mehr.
Die neue Konfiguration wird mit 'Datei- Speichern' gespeichert.

CaveRenderPro kann nun durch Doppelklicken der batch-Datei mit veränderten Einstellungen gestartet werden. Das Starten des Programms per Desktop-Icon erfolgt aber nach wie vor mit Standard-Einstellungen.

Das Benutzen der batch-Datei stellt allerdings nur eine Möglichkeit der schnellen Problemlösung dar und ist nicht als Standardmethode zum Programmstart gedacht.