AB3 : Debugger rev 567

[Blackbird]

Hallo,

Ich habe da mal wieder ein Problem mit dem Debugger.

Und zwar wenn ich eine variable tracen will, bekomme ich einen Reaperhit.

Vorgehensweise:

add Trace im Menue wählen

Fenster : Enter variable name: (öffnet sich)
Fenster : Show string lenght and maxlen? (öffnet sich)
Fenster : Variable trace (öffnet sich)

bis hierhin alles ok, dann Bäng----


Ich konnte den Fehler lokalisieren (mal wieder keinen verwertbaren Offset bekommen)

trotzdem gefunden 8-)

und zwar passiert es im Sprungpunkt

Code:

FindString:
  ad = Peek.l(?mybuffer)
  If (ad) Then ad2 = Peek.l(ad+52)
  ad = D_FindStringPtr(ad2,mem)
  If ad = -1
    ad = Peek.l(?mybuffer)
    If ad Then ad2 = Peek.l(ad+60)
    result.w = RTEZRequest(scrtitle$,"Findstring 7","_Ok")
    ad = D_FindStringPtr(ad2+$8000,mem) ; search in stack
  EndIf
Return

in der letzten Zeile
ad = D_FindStringPtr(ad2+$8000,mem) ; search in stack

:?:

Stack zu klein ? oder findet er die variable nicht weil im Direktmode ?

Auf jeden Fall dürfte es nicht reapern egal ob ers findet oder nicht.... :ugeek:

[Blackbird]

tomsmart ? Wanderer ? Bernd ?

nix nada keene Idee ? 8-)

[tomsmart1]

Habe dir eine EMail mit einer Testversion geschickt.

[tomsmart1]

So wir konnten den Fehler eingrenzen er tritt in der Funktion D_FindStringPtr(areg5,lookfor) der RiLesDebuglib.obj auf leider nur unter OS4.

So wie ich es verstanden habe versucht diese Funktion den Stringpointer der mit "lookfor" übergeben wird im Basicvariablespeicher zu finden. Dieser wird Adressiert über den Pointer der mit "areg5" übergeben wird, was dem Registerinhalt von A5 entsprechen soll, -32768. Die Routine prüft dann von dieser Adresse bis zur Adresse die in areg5 in 2 er Schritten. Wird eine Übereinstimmung gefunden wird dieser Adresse zurückgegeben wenn nicht -1.

Mir ist es jetzt auch gelungen dies Funktion in Basic nach zu bauen mit Loging so das man besser testen kann.
Ich habe den verdacht das bei OS4 vielleicht der Suchbereich zu groß ist.


Edit: Korrektur und Erweiterung 2016.02.06

[tomsmart1]

So wie es sich herausstellt tritt der Fehler nur mit bestimmen Sourcecodes auf bei kleineren wie den NTUI Examples funktioniert es mit der Anzeige und dem Tracen bis zum "End" Befehl, wird dieser erreicht gibt es einen Hit. Da macht der Debugger ein Fehler und macht beim Update des Variablefensters nach End des Programmes noch eine Zugriff.

Als Workaround kann man vor End eine Stop setzen und bei erreichen dieses das Menü "Misc / Del all..." aufrufen und dann Run oder Step aktivieren um das Programm zu beenden.

[tomsmart1]

So zur Info bevor ich es wieder vergesse ;-)

Der Fehler ist gefunden und ich kann ihn verhindern so zu den Details.

Zur Stringvariablen suche durchsucht der Debugger zuerst den Basicvariablen Speicherbereich das funktioniert auch unter OS4. Wird sie da nicht gefunden sucht er auf dem Stack und da ist das Problem die Stackadresse ist unter OS4 (Emulation) immer $00000000. Da keine Überprüfung auf ungleich Null stattfindet HIT und aus. Einfacher Fix dafür Testen ob die Stackadresse ungleich null ist und nur dann Suchen. Da mit der jetzigen Version ab der Stackadresse 32K durchsucht werden ist das auch nicht sicher da das Programm auch weniger als 32k Stack haben könnte, da brauchen wir noch eine andere Lösung wenn der Stack durchsucht werden soll bzw. muss.

Das Problem der OS4 68k Emulation ist das das Register User Stack Pointer kurz usp nicht gesetzt bzw unterstützt wird das zur Ermittelung der Stackadresse benutzt bzw. benötigt wird, man bekommt beim Auslesen immer $00000000 zurück.


PS. Positiver Nebeneffekt der Suche ich habe die Anzeige der Registerinhalte sowie die Disassembleranzeige für OS4 möglich gemacht plus noch ein paar Verbesserungen wie das die Fensterrahmen bei diesen Fenster nicht mehr überschrieben werden, Commit folgt in ein paar Tagen.

[tomsmart1]

So der Fehler sollte mit Revision 576 behoben sein!

Ich habe den Code so geändert das jetzt nur noch auf bzw. im Stack gesucht wird wenn der Pointer auf die Stringvariable im Variablespeicher nicht gefunden wird und die Stackdaten (Anfang und Ende) werden jetzt aus der Taskstruktur ausgelesen damit wird auch immer der ganze Programmstack untersucht egal welche Größe der Stack hat.

[Der Wanderer]

Ist euch aufgefallen, dass beim Debugger immer erst einmal auf "step" geklickt werden muss, damit er Variablen Inhalte anziegen kann, oder ist das nur bei mir so? Da ist scheinbar irgendwas noch nicht initialisiert beim ersten "stop".

[tomsmart1]

Ja ist bekannt, alles was kein .b, .w, .l muss erst Step darüber gemacht werden um es zu Tracen bzw. den aktuellen Wert angezeigt zu bekommen.
Soweit ich das bis jetzt Analysiert und verstanden habe ist das nicht anders lösbar aber ich habe noch nicht alles durch und verstanden.

[tomsmart1]

Habe es endlich geschafft mit Revision 600 haben jetzt die Verbesserungen für Variable-, Disassembler-, Register und Memoryfenster Einzug gehalten.
- bei diesen Fenstern wird jetzt der eingestellte Font benutzt und nicht mehr Topaz 8
- es wird nicht mehr über den Fensterrahmen geschrieben
- das Registerfenster ist jetzt in der Größe verstellbare Position und Größe werden gespeichert und nicht mehr zurückgesetzt
- Disassembler- und Registerfenster funktionieren jetzt unter OS4.1FE