Open mrdudz opened 2 years ago
Kann ich bestätigen, hatte das jetzt ein oder zweimal die Nacht beim testen. "Speicherzugriffsfehler" Da muss ich das loggen Mal erweitern und hoffen das es zumindest immer dann an der selben Stelle ist. Irgendwo läuft bestimmt noch ein Thread und ich lösche schon fleissig Speicher im Hauptthread. Werde das auch noch hinbekommen. Bin gerade wieder im Flow 😁
Die ersten 1000 mal lief er durch, na geil wird ja Lustig. Werde aber mal die paramter anpassen. Jetzt werde ich mal --minimized dazu nehmen.
#!/bin/bash
counter=1
while [ $counter -le 1000 ]
do
echo "Test Nr: " $counter
./emu64 --nosplash --limitcycles 5000000 --warp
((counter++))
echo "-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+"
done
Evtl. hängt es ja mit dem --exitscreenshot zusammen. Naja, da hilft nur geduldiges testen.
mit dem Aufruf waren es bei 1000 Starts 12 Abstürze. Das ganze läuft jetzt mit --nogui. Mal sehen wie sich das verhält.
./emu64 --nosplash --minimized --limitcycles 5000000 --warp >> ./emu64.log # 12 Abstürze
Ich sag mal vorsichtig es könnte an --minimized liegen. Mit dem Aufruf waren es bei 1000 Starts 0 Abstürze. Also mit --nogui kein einziger bei 1000. Teste gleich noch mit --minimized als Gegenkontrolle.
./emu64 --nosplash --nogui --limitcycles 5000000 --warp >> ./emu64.log # 0 Abstürze
Der zweite Durchlauf mit --minimized waren es lediglich 2 Abstürze auf 1000 Starts. Könnte also auch bei --nogui Zufall gewesen sein das da kein Absturz war. Werde mal dein Beispiel von oben nehmen aber mit --nogui und --exitscreenshot
jetzt läuft dieser Test. Bin mal gespannt.
#!/bin/bash
counter=1
while [ $counter -le 1000 ]
do
echo "Test Nr: " $counter >> ./emu64.log
./emu64 --reset-ini --video-filter-off --double-texture-off --set-palette 7 --warp --debugcart --nosplash --nogui --exitscreenshot ./screenshots/pic_$counter.png --limitcycles 10000000 --autostart ./sprite-sprite-collision-cycle.prg 1> /dev/null 2> /dev/null >> ./emu64.log
((counter++))
echo "-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+" >> ./emu64.log
done
Das obige Skript lief jetzt auch ohne Abstürze durch und erzeugte auch 1000 Screenshots. Morgen werde ich das alles noch mal länger testen. Aber mein jetzige Fazit lautet, das wahrscheinlich --minimized für die sporadischen Abstürze verantwortlich ist. Auch weil die Abstürze immer vor dem Aufruf des Destructors der MainWindow statt fand, also doch nicht beim beenden.
Ich hab hier einen der zuverlässig abstürzt:
emu64 --reset-ini --debugcart --mount-crt ../C64/carts/supergames//supergames.crt
und: ohne --debugcart geht es
Achja, und beim Durchlauf der Testsuite gab es noch immer eine Hand voll Abstürze, bis auf den oben immer sporadisch (also funktionierte dann beim zweiten mal) - diesmal nur mit --nogui und ohne --minimize und --nosplash
Ich hab hier einen der zuverlässig abstürzt:
Gut, den schaue ich mir genauer an. Ansonsten muss ich weitersuchen :)
Gerade bemerkt das Emu64 nicht richtig beendet wird wenn der WARP Modus aktiviert ist. Jedoch im normalen Modus also nicht mit--nogui. Evtl. gibt es da einen Zusammenhang. Muss ich ab prüfen.
Es ist so das Emu64 beim beenden hängen bleibt wenn im C64 Screen per HotKey (Alt+W) der Warp Modus aktiviert wurde. Wird das per Speed Window gemacht, wird Emu64 auch ordentlich beendet. Wird der Warp Modus beim Start mit über die Kommandozeile Übergeben wird Emu64 bei aktivierten Warp auch ordentlich beendet. Denke das hat dann doch nichts mit dem Problem hier zu tun. Werde dieses Problem von hier abkoppeln.
Mutex Behandlung aus EnableWarpMode entfernt, die Situation scheint etwas besser zu sein. Das Problem mit den sporadischen Abstützen bleibt aber vorerst bestehen, wobei sich hier bei mir ein Muster ergibt.
Diese hier stürzen besonders gerne und häufig ab ...
./testbench.sh emu64 cpujam // jamirq + jamnmi ./testbench.sh emu64 irqdma ./testbench.sh emu64 CIA-AcountsB
/testbench.sh emu64 cpujam // jamirq + jamnmi
vorsicht - DER Test MUSS abstürzen :)
Ja DER Test aber doch nicht mit Emu64 zusammen ;)
Ich habe die Testbench jetzt mal über nacht laufen lassen... dabei sieht man dass der Emu manchmal, in einem zufälligen Muster, abstürzt. Ich rate mal dass das beim Beenden passiert, dann da hatten wir sowohl bei VICE als auch bei anderen Emulatoren schon das gleiche Problem, idr irgendwelche Unsauberkeiten beim Freigeben von Speicher - oder der Synchronisation von Threads. Wenn man den gleichen Test dann nochmal startet funktioniert es in der Regel, es liegt also nicht am Test selber.
Leider der Worst-Case zum Debuggen, ich weiss :)
Hier mal ein Beispiel einer vollständigen Kommandozeile:
(Das war jetzt ohne deine letzten Änderungen - das bastel ich im Laufe des Tages rein und lass dann diese Nacht nochmal laufen :))