AmiBlitz3 : Compiler Hunkoffsets

[Blackbird]

Hallo,

Mir ist da gerade was "komisches" aufgefallen in den dbg.files meines Programmes...

Da werden ja die Hunk Offsets als erstes, dann woher im Code es kommt, und anschließend die Zeilennummer ausgegeben...

Jetzt wundere ich mich gerade darüber das scheinbar Einträge fehlen (?)

Ein Beispiel:

In meinem Programmcode steht :

[ab3]; Dies ist der Hauptsource zu Tincture
; alle Rechte bei Marco Moering aka Blackbird
!version{"Tincture 0.2 (\\__DATE_GER__) Build \\__VER_BUILD"}

optimize 7
Syntax 2

XINCLUDE "dos.include.bb2"
XINCLUDE "ntui.include.bb2"
usw usf....[/ab3]

im dbg.file wird das so ausgegeben:

00000008 <Tincture.Main.ab3@0>
0000003A <Tincture.Main.ab3@3> !version{"Tincture 0.2 (\\__DATE_GER__) Build \\__VER_BUILD"}
00000046 <Tincture.Main.ab3@5> optimize 7
00000046 <dos.include.ab3@1> XINCLUDE "dos.include.bb2"
00000046 <error.include.bb2@1> XINCLUDE "dos.include.bb2"
usw usf....

da fehlt nun der Eintrag für Syntax 2

da ich zum späteren auf syntax 6 umschalte und dieser Eintrag ebenso fehlt, stellen sich mir die Fragen warum ? und könnte das auch daran liegen das nun unter OS4 die Offsets nicht passen ?

ich denke mal da läuft was falsch, weil das optimize wird ja als Befehl ebenso aufgelistet...

[Der Wanderer]

"Syntax" ist eine Compiler Direktive und erzeugt keinen Code. Deshalb gibt es, genauso wie für leere Zeilen oder reine Kommentarzeilen keinen Eintrag in der .dbg. "optimize" ist auch eine Direktive, erscheint aber trotzdem weil <Gelästere über den Compiler...>.
Will heissen, ist schon ok, kein Bug im Sinne von dass was wirklich schief läuft.

[Blackbird]

Hmpf, na daaaa bin ich ja "beruhigt".... :?

An was könnte es denn liegen das die Offsets nicht mehr passen ?
JIT (Petunia)
Dos
GrimReaper

:?:

Ich habe auch schon ausprobiert Petunia beim starten ganz wegzulassen...half auch nicht...deshalb kann ich den JIT schon ausschließen
Manchmal klappts aber, und ich bekomme verwertbare Offsets...Nur, ob man sich darauf 100% verlassen kann, oder ob das dann nur "Zufall ist" kann ich auch nicht sagen.

[Der Wanderer]

Also das Mapping "Offset => Codezeile" ist korrekt. Die Frage ist nur welche Tools und einstellungen du verwenden musst um im Falle eines crashes den korrekten offset zu ermitteln.
Bei einem Stack-Tash kann es aber leicht passieren, dass sich keine verwertbaren Offsets mehr ermitteln lassen, da die Rücksprungadressen nunmal auf dem Stack liegen. Will heissen, nicht bei jedem Crash gibt es hinterher ein vernünftigen Stack Trace mit Offsets. Ausserdem musst du drauf auchten, dass oftmals die oberste Adresse im Stack Trace Müll ist (z.B. bei Illegal Instruction Guru). Meistens ist der zweite oder dritte Eintrag erst sinnvoll.

Ansonsten hätte ich auf JIT getippt, da ja dort die 68K instructions nicht der Reihe nach ausgeführt werden. Bei WinUAE geht es allerdings mit JIT.

[Blackbird]

Das verstehe ich in doppelter Hinsicht nicht so ganz. Es funktioniert ja schonmal problemlos, und ich konnte Offsets bei jedem Crash ermittlen per GrimReaper.

Geändert unter OS4 hat sich nur der Grimmreaper und DOS

Ich habe zur Ausgabe Sashimi im Hintergrund laufen. Wenns arg schlimm ist, dann kann ich noch Memguard zusätzlich starten. Aber der gibt mir nur Memfehler aus.

Den Stack ansich haben wir auch schon in Verdacht gehabt und sicherheitshalber auf das dreifache erhöht weil OS4 mehr braucht. Geändert hat sich nix.

[Der Wanderer]

Stack Trash kommt nicht davon, dass er überläuft (stack Overflow), sondern dass Teile mit Müll überschrieben werden. Wenn dann ein "RTS" kommt, und sich die Rücksprungaddresse vom Stack holt (wo jetzt Müll steht), dann macht es Peng!.

[Blackbird]

Das ist mir schon klar, gerade bei Ntui macht es des öffteren Peng wenn man sich z.B im xmlfile einmal verschreibt, oder ein falsches attribut verwendet
Da kommt dann zwar noch der Requester der einem sagt welches Attribut er nicht bearbeiten kann, aber nach dem Klick auf ok, und nachdem die zerstückelte Gui bis der Fehler auftrat erscheint, geht halt dann nix mehr....

Primär gehts mir eigentlich darum ob ich das wieder hinbekomme das die Offsetausgabe wieder zuverläßig funktioniert...
Ich muß da mal was ausprobieren mit einem alten Code...Ich habe da so einen Verdacht...

[Der Wanderer]

NTUI hört auf zu parsen, wenn es im XML auf einen Fehler trifft. Es crashed aber nicht. Wenn es doch crashed, dann ist es vermutlich deine Code, weil du irgendwo direkt auf ein NTUI Objekt zugreifst ohne auf NULL Pointer zu testen.

Evtl. sollte NTUI bei einem Fehler sich komplett weigern, die Datei anzunehmen. Was meinst du? Das würde halbfertige GUIs verhindern.
Weiterparsen ist im Falle eines simplen Schreibfehlers zwar möglich, aber wenn die XML Datei kaputt ist könnte dadruch NTUI Amok laufen, da irrwitzig riessige GUIs gebaut werden.

[Blackbird]

Ich wäre dafür das Ntui einen Requester zeigt der den Fehler anzeigt und sich dann beendet, das ist am sichersten...

Klar checke ich nicht alles auf 0, deswegen wird es dann crashen, weil das Programm davon ausgeht das das Gui exestiert, da hast du natürlich Recht...

Manchmal (wirklich selten) kommt es vor das Ntui beim bau der Guidie Systemlast auf 100% schießen läßt, aber das Gui nie erscheint...
Ich habe nur noch nicht rausgefunden unter welchen Umständen....

[Der Wanderer]

Wenn NTUI beim bauen freezed, schicke mir bitte den XML Code.

NTUI kann dir deine App nicht beenden. Aber ich werde dann das bauen abbrechen, das bereits gebaute frei geben und NULL zurück geben, so kann der App Programmierer darauf reagieren wie er möchte. Das halbfertige GUIs gebaut werden gefällt mir auch nicht.
Und du solltest beim bauen IMMER checken ob es geklappt hat. Genauso wenn du dir einen Pointer per GetObjectByID holst. Kann IMMER fehlschlagen, so wie Datei oder URLs öffnen.