Wie gewünscht, möchte ich hier erklären, wie ich vorgegangen bin. Ich mache keinen eigenen Thread dafür auf, weil das Vorgehen von Problem zu Problem sehr unterschiedlich ist und ich es daher nur am Beispiel von TANGO.PRG beschreibe.
Aufgrund von dbsys' Fehlerbeschreibung habe ich das Programm mit TOS 2.06 in Steem gestartet und zwar in der Debug-Version von Steem. Die bietet u.a. die Möglichkeit, Speicherinhalt und Disassembly des ST zu sehen und Schritt für Schritt durch ein Programm durchzu"step"pen. Insbesondere wird der Debugger auch aktiv, wenn ein Programm auf dem ST abstürzt.
So konnte ich sehr schnell herausfinden dass der Absturz an Adresse 0xE0E16A (im TOS-ROM) stattfindet, weil ein 16-bit breiter Zugriff auf die Adresse 0xFF0001 versucht wird. Auf ungerade Adressen darf nur byte-breit zugegriffen werden, sonst gibt es einen Address Error mit 3 Bomben. Aber ohnehin ist diese Adresse unsinnig, da in einem "normalen" ST(E) nichts an dieser Speicheradresse ist. Wenn ein Absturz im TOS passiert, ist die wahrscheinlichste Ursache, dass irgendeine Betriebssystemfunktion mit falschen Daten aufgerufen wird.
Warum aber dieser Speicherzugriff und in welcher Funktion? Dazu bin ich zu Hatari gewechselt, der ebenfalls einen eingebauten Debugger hat. Dieser ist von der Bedienung nicht so komfortabel wie der von Steem, erlaubt es aber dafür, die Funktionsnummern von aufgerufenen BIOS-, XBIOS-, GEMDOS-, VDI- und AES-Funktionen zu protokollieren. Daran konnte ich erkennen, dass die letzte aufgerufene Funktion objc_draw im AES war, die einen Baum an Objekten (also GUI-Elementen, die z.B. aus einer Resource-Datei stammen oder in diesem Fall im Programm eingebunden sind) auf dem Bildschirm darstellt.
Ein Blick ins Atari Profibuch verrät, wie und mit welchen Parametern objc_draw aufgerufen wird. Der Objektbaum ist der komplexeste Parameter, der an objc_draw übergeben wird, also ist es am wahrscheinlichsten, dass der Fehler dort liegt. Anhand der Dokumentation im Profibuch konnte ich mich im Hatari-Debugger durch den Speicher des ST hangeln, bis ich bei besagtem Objektbaum angekommen war. Ich habe den Objektbaum zur einfacheren Analyse in einer Datei ge"dump"t.
Das Profibuch erläutert auch die Struktur des Objektbaums, den ich mir im Hexeditor angesehen habe. Ein Großteil der Objekte im betroffenen Baum sind von Typ einfache GUI-Elemente wie Rahmen, Texte oder Buttons. Aber zwei sind Bilder. Auch hier gilt wieder, dass die Wahrscheinlichkeit größer ist, dass komplizierte Datenstrukturen (wie die Bilder) korrupt sind. Also habe ich mir die Bilder gezielt vorgenommen und bin (wieder in Hatari) deren Speicheradressen nachgegangen. Ein Bildeintrag zeigt auf eine korrekte BITBLK-Struktur, der andere hingegen nicht. Offensichtlich ist beim Eincompilieren der Bilder in TANGO.PRG etwas schief gelaufen.
Da die Bilder nur den Start-Bildschirm verschönern, habe ich den Eintrag des zweiten Bilds im Objektbaum wieder mit dem Hexeditor in TANGO.PRG so verbogen, dass es auf die Daten des ersten Bilds zeigt. Test zeigt: Absturz behoben.
Thema: Unterschiede zw. TOS 2.06 und TOS 1.62 auf einem 1040STE (Gelesen 16409 mal)