|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Programmierung > OS4 Emu | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| -1- 2 | [ - Beitrag schreiben - ] |
|
09.12.2007, 16:18 Uhr MaikG Posts: 5172 Nutzer |
Ich hab einen befehl wie STR$(a&/1000) STR$ macht nichts anderes als eine Variable zum String zu wandeln. a&/1000 Teilt die LONG a druch 1000. Ja, das ist nun eigentlich nicht was irgenwie mit Librarys oder so zu tun hat, aber es geht nicht. Hingegen: b&=a&/1000 STR$(b&) geht. Ist das der Emulation zuviel oder wie? Dagegen gehen unsaubere Sachen, wie zugriff auf bereits freigegebenen Speicher eigenartigerweise schon. [ - Antworten - Zitieren - Direktlink - ] |
|
09.12.2007, 17:34 Uhr Der_Wanderer Posts: 1229 Nutzer |
Welche Sprache, welches System ? Sieht so aus, als ob der Compiler eben anderen Code erzeugt, der in einem Falle geht und im anderen nicht. > Ist das der Emulation zuviel oder wie? Die Emualtion führt ja keinen Basic code aus, sondern das resultierende Compilat. Müsste man mal disassemblieren was das passiert. Wäre es eine Sprache wie Amiblitz, die noch entwicklet wird, könnte man den Compiler fixen. -- Thilo Köhler, Author von: HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
09.12.2007, 17:54 Uhr MaikG Posts: 5172 Nutzer |
>Welche Sprache, welches System ? MaxonBasic und Classic (A4000) natürlich. >Sieht so aus, als ob der Compiler eben anderen Code erzeugt, >der in einem Falle geht und im anderen nicht. Möglich, aber solche befehle greifen nicht auf Customchips zu, nicht auf Librarys etc. Also kann ich mir nicht vorstellen was da nicht Systemkonform sein soll. >Die Emualtion führt ja keinen Basic code aus, sondern das >resultierende Compilat. Müsste man mal disassemblieren was das >passiert. Ja, das ist schon klar. Da auch die Library gelinkt wird ist das schon 20 kb groß und da genau den Code zu finden... [ - Antworten - Zitieren - Direktlink - ] |
|
10.12.2007, 11:29 Uhr ZeroG Posts: 1487 Nutzer |
@MaikG: Also zu allererst muß ich mal sagen das das Threadthema komplett irreführend ist. OS4Emu ist ein MOS Programm, da fällt es nicht gerade leicht drauf zu kommen das es hier um die 68k-Emulation von OS4 geht. So, hast du das ganze mit oder ohne JIT probiert? Was sagt der Grimreaper dazu, wie sieht das Crashlog aus? [ - Antworten - Zitieren - Direktlink - ] |
|
10.12.2007, 15:32 Uhr MaikG Posts: 5172 Nutzer |
>Also zu allererst muß ich mal sagen das das Threadthema komplett >irreführend ist. >OS4Emu ist ein MOS Programm, da fällt es nicht gerade leicht drauf >zu kommen das es hier um die 68k-Emulation von OS4 geht. Sorry, was wirklich passendes, kurzes ist mir nicht eingefallen. >So, hast du das ganze mit oder ohne JIT probiert? Beides natürlich. >Was sagt der Grimreaper dazu, wie sieht das Crashlog aus? Also da muss ich sagen, ich komme mit Enforcer klar, mit Cyberquard klar, aber den Grimreper kann ich nichts entnehmen was ich in irgendeiner weise interpretieren kann. Ich konnt einmal auch fortsetzen, dann wurde statt sagen wir 500 eine Floatingpoint zahl ausgegeben. [ - Antworten - Zitieren - Direktlink - ] |
|
10.12.2007, 16:05 Uhr ZeroG Posts: 1487 Nutzer |
@MaikG:Zitat:Ok, wenns mit und ohne JIT abstürzt ist es schonmal kein Bug im JIT.  Zitat:Dann setzt doch hier mal das komplette Crashlog rein, im GR gibts ja einen Knopf um das Ding zu speichern. Wenns geht bitte ein Log von einem Absturz ohne JIT. (Der JIT verschiebt ein paar Addressen, also ist zum debuggen von 68k-Zeug am besten ein Log zu gebrauchen das ohne JIT entstanden ist.) [ - Antworten - Zitieren - Direktlink - ] |
|
10.12.2007, 16:23 Uhr MaikG Posts: 5172 Nutzer |
a&=50000 print str$(a&/1000) Crash log for task "Test" Generated by GrimReaper 52.4 Crash occured in module kernel at address 0x08215590 Type of crash: program exception Register dump: GPR (General Purpose Registers): 0: 08227B30 3EA7FF60 100E1110 8000000B 00000000 0000000C 0000000A 00800000 8: 08645EE0 08696B56 0868E650 08696B57 48002222 11100E11 3EECF0A0 0034000F 16: 9FFA3B00 FFFFFFFF 3EE0CA80 3EB52850 0882F68C 00000000 08791D0A 00000000 24: 00000001 3EB529B8 7FFFFFFF 80000014 3EF19740 3F321582 3FFF9140 00000000 FPR (Floating Point Registers, NaN = Not a Number): 0: nan 4.19374e-309 5.67894e-299 2.84864e-260 4: 3.26001e-265 5.97523e-299 5.37793e-299 3.90152e-308 8: 3.39035e-43 4.6905e-09 1.78065e-235 1.18938e-134 12: 12.0591 3.03342e-284 1.42904e-284 9.73474e-309 16: 3.19914e-308 9.163e-130 1.1684e+78 7.23155e-308 20: 50 10000 2.50324e-308 5.9528e-236 24: 2.29731e+155 1.06758e-167 6.13473e-130 6.28161e-77 28: 2.23321e-187 7.20566e-241 5.77053e+53 1.78002e-133 FPSCR (Floating Point Status and Control Register): 0x201F0000 SPRs (Special Purpose Registers): Machine State (msr) : 0x0002F070 Condition (cr) : 0x48002282 Instruction Pointer (ip) : 0x08215590 Xtended Exception (xer) : 0x20000200 Count (ctr) : 0x0822D10C Link (lr) : 0x0820796C DSI Status (dsisr) : 0x00017D07 Data Address (dar) : 0x00017360 680x0 emulated registers: DATA: 00004049 00000000 40C38800 00000000 0000001A 00000000 00000000 40490000 ADDR: 3EA7FFBC 3EB3505F 3EF01E44 3F328008 3EA7FFE4 3EF01004 3EF01FB8 3EA7FFB8 FPU0: 50 0 0 0 FPU4: 0 0 0 0 Symbol info: Instruction pointer 0x08215590 belongs to module "kernel" (HUNK/Kickstart) Stack trace: native kernel module kernel+0x00015590 native kernel module kernel+0x00027b30 native kernel module kernel+0x000468b8 native kernel module kernel+0x00053b84 PPC disassembly: 08215588: 4bfffff0 b 0x8215578 0821558c: 60000000 nop *08215590: 7fe00008 trap 08215594: 4e800020 blr 08215598: 3c600821 lis r3,2081 [ - Antworten - Zitieren - Direktlink - ] |
|
10.12.2007, 19:06 Uhr TetiSoft Posts: 197 Nutzer |
Zitat:Der GrimReaper hat seine Stärken beim Suchen von Bugs in PPC-Programmen, zusammen mit addr2line bekommt man oft leicht raus in welcher Quellcode-Zeile genau der Fehler steckt. Bei 68k-Programmen ist es schwieriger weil ja nicht der 68k-Code abstürzt sondern der PPC-Code den Petunia daraus gemacht hat, oder der interpretierende 68k-Emulator wenn man Petunia deaktiviert hat. Es gibr eine Umgebungsvariable "Reaper.68kStacktrace" oder so ähnlich (such in GrimReaper selbst oder im kernel), die ist numerisch und gibt die Anzahl der Stacktrace-Zeilen für 68k an, damit und OHNE Petunia kann man machmal aus einem GrimReaper-Log heraus erkennen wo im 68k-Programm der Fehler liegt. [ - Antworten - Zitieren - Direktlink - ] |
|
10.12.2007, 19:36 Uhr TetiSoft Posts: 197 Nutzer |
Zitat: Das war eine Steilvorlage denke ich  In einem anderen Thread wollte ich darauf hinweisen daß fehlender Assembler-Quellcode bei größeren (30k) Binaries in Arbeit ausarten könnte, Deine Antwort war Zitat: Wenn Du vor und nach der Stelle irgendwas einfügst das sich im Disassembler leicht finden läßt, eine Ausgabe eines suchbaren Textes z.B., sollte es leichter werden. [ - Antworten - Zitieren - Direktlink - ] |
|
10.12.2007, 23:32 Uhr MaikG Posts: 5172 Nutzer |
>In einem anderen Thread wollte ich darauf hinweisen daß >fehlender Assembler-Quellcode bei größeren (30k) Binaries >in Arbeit ausarten könnte, Deine Antwort war Ich bin bloß faul. Nein, in Assembler hab ich nur relativ wenig gemacht und das meiste war auch schon sehr lange her. >Wenn Du vor und nach der Stelle irgendwas einfügst das sich im >Disassembler leicht finden läßt, eine Ausgabe eines suchbaren >Textes z.B., sollte es leichter werden. Der Compiler kann Text ja ablegen wo er will, von daher bringt das auch nichts. Früher hab ich z.B. in einem Programm die OpenScreen Taglist zuerst per Library Einsprung gesucht(HexEditor) aber da waren oft nicht die zu modifizierenden Daten... [ - Antworten - Zitieren - Direktlink - ] |
|
11.12.2007, 01:12 Uhr TetiSoft Posts: 197 Nutzer |
Zitat:Wenn der Disassembler was taugt hat jeder Text einen Label und dieser Label wird im Code genau einmal referenziert. Hängt natürlich auch davon ab was das Basic da genau für einen Code produziert. Oder sei doch schlau und disassembliere zwei Versionen die sich nur in der verwendeten Konstanten im Quellcode unterscheiden und mach ein diff, dann findest Du schonmal wo Dein eigener Code eigentlich liegt weil Startup und linker-Libs ja gleich bleiben. [ - Antworten - Zitieren - Direktlink - ] |
|
11.12.2007, 11:12 Uhr thomas Posts: 7718 Nutzer |
Zitat:   -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
11.12.2007, 12:14 Uhr Holger Posts: 8116 Nutzer |
Zitat: Das wundert mich eigentlich nicht. In Basic ist x/y immer eine Floating-Point Operation, selbst dann, wenn beide Operatoren (und sogar die Zielvariable) einen Integer-Typ besitzen. Einfach zu Erkennen, a&=42 b&=a&/22 liefert eine 2 in b&, also das FP-Ergebnis wurde nach Integer gerundet. Du führst also zwei völlig verschiedene Operationen durch. Im ersten Fall lässt Du eine Floating-Point Zahl in einen String umwandeln, im zweiten Fall rundest Du zuerst in ein Integer und lässt dann einen Integer in einen String umwandeln. Damit ist klar, dass der Fehler in der Umwandlung einer FP-Zahl in einen String liegt. Das kannst Du ja auch Testen... ? STR$(RND(0)) mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
11.12.2007, 14:58 Uhr MaikG Posts: 5172 Nutzer |
>Das kannst Du ja auch Testen... Klingt eigenartig. RND ist eine Floating Point, wie auch TIMER aber mit Defint a-z lege ich doch alles als Integer fest. [ - Antworten - Zitieren - Direktlink - ] |
|
11.12.2007, 15:56 Uhr MaikG Posts: 5172 Nutzer |
Scheint aber zu stimmen, denn das 2. Beispiel braucht doppelt so lang wie das erste. Da die Variablen an Verschiedenen Positionen an komischen stellen im Programm liegen konnte ich auf die schnelle nicht den entsprechenden Code finden. [ - Antworten - Zitieren - Direktlink - ] |
|
12.12.2007, 09:59 Uhr Solar Posts: 3680 Nutzer |
Zitat: Deine Art der Fehlerdiagnose finde ich immer wieder faszinierend.  [ - Antworten - Zitieren - Direktlink - ] |
|
12.12.2007, 10:04 Uhr MrMarco Posts: 445 Nutzer |
Sieh es mal so... Würde er bei uns beiden in der Firma arbeiten, dann hätten wir unseren Spaß  Stell dir mal vor er schreibt einen Unittest auf diese Art und die Fachabteilung stellt fest, dass hier bei den Beträgen ein paar Mio Differenz dann sind *G* DAS wird ein Spaß! Den Anpfiff hören wir auf der anderen Gebäudeseite noch [ - Antworten - Zitieren - Direktlink - ] |
|
12.12.2007, 10:05 Uhr Solar Posts: 3680 Nutzer |
 [ - Antworten - Zitieren - Direktlink - ] |
|
12.12.2007, 10:12 Uhr MaikG Posts: 5172 Nutzer |
>Deine Art der Fehlerdiagnose finde ich immer wieder faszinierend. Hast du irgendwas sinnvolles zum Thema beizutragen? Holger ist sehr kompetent, weil mir dieses verhalten von Basic nicht bekannt ist machte ich einen Test. Trotz benutzung einer 2. Variable wird das Programm doppelt so schnell. Was nur heissen kann das im fall eine doppelt so komplizierte Operation läuft. Eine LONG hat die halbe länge einer Floating-Point, dazu kommt das FPU berechnungen immer langsamer sind. Dann natürlich die FP ausgabe in OS4. Ja, aber wem erzähle ich das. Du kannst ja gar nicht Programmieren so weit ich weiss. [ - Antworten - Zitieren - Direktlink - ] |
|
12.12.2007, 10:22 Uhr Robin Posts: 1056 Nutzer |
@MaikG: > Du kannst ja gar nicht Programmieren so weit ich weiss. Öhm ... http://www.rootdirectory.de/resume.html -- (Bild) http://my.morphosi.net/ morphos [ - Antworten - Zitieren - Direktlink - ] |
|
12.12.2007, 10:39 Uhr Solar Posts: 3680 Nutzer |
Zitat: Hätte ich wohl, wenn ich irgendwelche Hoffnung hätte, daß Du aufnahmebereit wärst. Ich könnte Dir sicher einiges zum Thema Softwaretest, Fehlerdiagnose und Problembeschreibung beibringen. Es würde Dir mit Sicherheit auch helfen in der Kommunikation mit anderen Entwicklern. Falls ich mich getäuscht haben sollte und Du Interesse hast, melde Dich einfach mal über PN und ich höre auf zu feixen. [ - Antworten - Zitieren - Direktlink - ] |
|
12.12.2007, 17:19 Uhr ylf Posts: 4112 Nutzer |
@MrMarco & Solar: ist euch langweilig auf der Arbeit oder warum treibt ihr euch hier wieder herum? [ - Antworten - Zitieren - Direktlink - ] |
|
12.12.2007, 17:37 Uhr Solar Posts: 3680 Nutzer |
Jup. Edit: Nee, die Slashdotter waren gemein zu uns. Edit2: ...oder, draußen war's uns zu kalt und wir holen uns hier ein bißchen Nestwärme. [ Dieser Beitrag wurde von Solar am 12.12.2007 um 17:38 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
12.12.2007, 18:17 Uhr MaikG Posts: 5172 Nutzer |
>Ich könnte Dir sicher einiges zum Thema Softwaretest, >Fehlerdiagnose und Problembeschreibung beibringen. An meinen vielen Bugreports hatte bissher keiner was auszusetzen. Logisch das dies per Forum nicht grade gut geht, ich will hier z.B. auch nicht alles mit Crashlogs zumölen. [ - Antworten - Zitieren - Direktlink - ] |
|
12.12.2007, 18:43 Uhr ZeroG Posts: 1487 Nutzer |
@MaikG:Zitat:Genau das ist aber im moment (leider) die einzigste möglichkeit als nicht Betatester Bugreports zu OS4 Systemteilen loszuwerden. Oder man weiß durch Zufall wer für das fragliche Systemteil zuständig ist und macht es direkt. Falls direkt: NUR Bugreports/Crashlogs von OS4 Systemteilen, nicht von jedem 68k-Spiel/-Anwendung/-Sonstwas was bei dir unter OS4 bei dir absemmelt. EDIT: Zitat:Also die ersten 4 Zeilen + Stacktrace bei DSIs reichen zum nachfragen. [ Dieser Beitrag wurde von ZeroG am 13.12.2007 um 11:37 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
12.12.2007, 23:24 Uhr MaikG Posts: 5172 Nutzer |
>Falls direkt: >NUR Bugreports/Crashlogs von OS4 Systemteilen, nicht von jedem >68k-Spiel/-Anwendung/-Sonstwas was bei dir unter OS4 bei dir >absemmelt. Bei letzteren würde das wohl das Postfach sprengen. Trotzdem wo sollte ich ein Crashlog hinsenden? Die Hyperion Seite sieht irgendwie so minmalistisch aus, legentlich zum Speichermanagement gibts eine Erklärung. Z.b. hab ich eins von Prefs/GUI. Meistens schmiert Grimp aber ab bevor man das Log speichern kann. [ - Antworten - Zitieren - Direktlink - ] |
|
13.12.2007, 01:41 Uhr ZeroG Posts: 1487 Nutzer |
@MaikG: Keine Ahnung wer für Prefs/GUI zuständig ist. Zitat:An die Entwickler direkt. Dazu muß man allerdings die entsprechenden EMail-Addressen kennen, und wissen das der Entwickler da wirklich seine Finger dran hatte. Ab und zu findet man dazu Hinweise wenn man die Forenbeiträge ließt. Du kannst eigendlich nur ein neues Thema mit dem Titel "OS4 Crashlog zu <Systemteil>" aufmachen, oder einen Betatester/Entwickler fragen ob er es weiterleitet. Ist nicht optimal ist aber so, den EMail-Support sollte wohl Amiga <wasgeradeaktuellist> machen, in der letzten A1 Version findet man noch eine (vermutlich tote, wir kennen die ja inzwischen) EMail-Addresse von denen. Ist aber bekanntlich alles anders gekommen. Zitat: Zum Glück gibts jetzt zwei Arten den Amiga zu Reseten - Soft (Kickstart wird nicht nochmal geladen) - Hard (wie direkt nach dem Anschalten) Wenn der Grim also auch abschmiert und ein SoftReset (CTRL-AMIGA-AMIGA) den Amiga wieder erfolgreich nach OS4 bringt, kann man in einer Shell mit dumpdebugbuffer ram:crash.log das Crashlog noch retten. Praktisch was? [ - Antworten - Zitieren - Direktlink - ] |
|
13.12.2007, 10:21 Uhr Solar Posts: 3680 Nutzer |
Zitat: Es war mir zu blöd, deswegen in der Historie irgendwelcher Threads herumzugraben, aber dankenswerterweise brauchte ich das ja gar nicht... [ - Antworten - Zitieren - Direktlink - ] |
|
13.12.2007, 10:29 Uhr MaikG Posts: 5172 Nutzer |
>dumpdebugbuffer ram:crash.log >das Crashlog noch retten. Praktisch was? Mh, fürs Debuggen ja, für den Speicherkonsum eher nicht. >Es war mir zu blöd, deswegen in der Historie irgendwelcher Threads >herumzugraben, aber dankenswerterweise brauchte ich das ja gar nicht... Ich rede von richtigen Bugreports per Email. [ - Antworten - Zitieren - Direktlink - ] |
|
13.12.2007, 11:33 Uhr ZeroG Posts: 1487 Nutzer |
@MaikGZitat:Woher wusste ich nur das das wieder kommt... Lese mal die Dokumentation vom Kernel, da steht wie du das auf die serielle Schnittstelle einstellst. Aber dann mußt du einen 2. Computer per Nullmodemkabel dran und auf empfang haben, wenn nicht geht der Report ins nichts. Kann auch sein das man da irgendwo die Buffergröße einstellen kann. Ich denke das es so wie es ist am besten ist. Niemand kann zu 100% vorhersagen wann und unter welchen Umständen sowas passiert, muß ja nicht unbedingt ein Systemteil sein, die Authoren von Spielen/Anwendungen, wollen ja auch ihre Reports. Gerade die Crashes die nur sehr selten Vorkommen sind aus Entwicklersicht am interressantesten. Zitat: Und was bitte ist daran so schwer eine vernümpftige und wirklich informative Beschreibung des Fehlers in ein Forum zu schreiben, wenn du sowieso schon A gesagt hast? Warum muß da aus deiner Sicht unbedingt ein B per Mail kommen? Ich hab in meinem Post vom 12.12. übrigens noch ein Zitat von TetiSoft auf OS4Welt angehängt, hatte ich da vergessen. Vielleicht schreibst du ja eher in ein Forum wenn du nicht das ganze Log schicken mußt. [ - Antworten - Zitieren - Direktlink - ] |
| -1- 2 | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Programmierung > OS4 Emu | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|
