|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Programmierung > Wie aus GrimReaper Protokoll auf Ursache im Code zurückfinden? | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| -1- | [ - Beitrag schreiben - ] |
|
15.08.2009, 23:37 Uhr Reth Posts: 1858 Nutzer |
Hallo zusammen, wie ja z.T. bekannt ist, versuche ich mich gerade an der Portierung eines SDL-Spieles auf AOS4. Dazu verwende ich CodeBench 0.8. Nun klappen compile und linking, aber wie erwartet treten Probleme zur Laufzeit auf. Dort grüßt mich ein GR, bei dem man nicht mal mehr auf Ignorieren klicken kann. Das Protokoll sagt mir, dass der Fehler wohl innerhalb einiger SDL-Funktionen auftrat (die aber bestimmt aus dem Code heraus falsch gefüttert sind). Da Debugging wohl nicht mit Codebench zu funktionieren scheint und einem IDE-verwöhnten Programmierer auf dem Amiga derzeit für AOS4 auch nicht beschieden ist besteht derzeit mein Versuch mich der verursachenden Stelle durch Logausgaben zu nähern. Das ist aber mehr als mühselig und umständlich! Daher wäre die Interpretation des GR-Protokolls sicher sehr hilfreich bei der Ursachenforschung. Geht das denn irgendwie? Vielen Dank schon einmal! Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
16.08.2009, 05:25 Uhr AGSzabo Posts: 1663 Nutzer |
@Reth: hm, tja das wüsste ich auch gerne. in den seltensten fällen hilft mir die meldung weiter, weil sie erst irgendwo im os auftritt statt in meinem programm. dazu kommt noch, das ich in 68k asm programmiere... da kommt die meldung meistens auch an einer ganz anderen stelle im source zum vorschein... -- Sam os4.1, e-uae 39bb2 - A4000d 39bb2 - Cyberst.MK3 060 50mhz 128mb - Cybervis. - Ariadne_II - ide DVD und 320gb HD (nur 128gb) - HD Floppy -- A500 3.1 adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110 [ - Antworten - Zitieren - Direktlink - ] |
|
16.08.2009, 09:32 Uhr tboeckel Posts: 124 Nutzer |
@Reth:Zitat: Den gesamten Code mit "-g -gstabs" compilieren und die Offsets aus dem Crashlog an addr2line weiterreichen: Wenn man diese Zeile im Crashlog hat: code:programm:funktion()+offset1 (section 1 @ offset2) dann ruft man addr2line so auf: addr2line -j .text -f -e programm offset2 Falls der Crash in einem Modul passiert ist, das ohne Debugginginfos compiliert wurde, dann einfach solange die Offsets im Crashlog von oben nach unten durchgehen bis man was sinnvolles findet. Der Crash passiert zwar in der obersten Zeile, wird aber oft durch falsche Parameter in den Funktionsaufrufen davor ausgelöst. [ - Antworten - Zitieren - Direktlink - ] |
|
16.08.2009, 10:12 Uhr ZeroG Posts: 1487 Nutzer |
@Reth: http://hdrlab.org.nz/using-crash-logs/ [ - Antworten - Zitieren - Direktlink - ] |
|
16.08.2009, 22:03 Uhr Reth Posts: 1858 Nutzer |
@All: Vielen Dank für die guten Tips und Hilfen! Wusste gar nicht, dass Hans das auch auf seiner Seite hat! Der Fehler tritt bei mir innerhalb von SDL_FreeSurface auf, die zuvor für andere Bilder einwandfrei funktioniert hat. Meine Vermutung ist, dass es am Format des Bildes liegt, da bei einem ILBM-Amiga-Bild ausgestiegen wird, PNGs anscheinend aber super funktionieren. Scheint evtl. auch ne Amiga-Eigenheit zu sein, da dass PC-Executable, das auf der GigaLoMania-Website vorhanden ist mit den Amiga-Daten zusammen wunderbar funktionier! Ciao [ Dieser Beitrag wurde von Reth am 16.08.2009 um 23:11 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
17.08.2009, 15:24 Uhr AGSzabo Posts: 1663 Nutzer |
gibts da vielleicht auch eine möglichkeit um im falle von 68k code etwas mehr ueber den fehler zu erfahren? ich habe das rpogramm mit debug und sysmbols aktiv assembliert bekan aber keine zusätzlichen infos wie zb zeilennummr oder funktionsname. dabein muesste es imo recht einfach sein bei einem code der sowieso schon emuliert wird, an diese infos ran zu kommen... -- Sam os4.1, e-uae 39bb2 - A4000d 39bb2 - Cyberst.MK3 060 50mhz 128mb - Cybervis. - Ariadne_II - ide DVD und 320gb HD (nur 128gb) - HD Floppy -- A500 3.1 adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110 [ - Antworten - Zitieren - Direktlink - ] |
|
17.08.2009, 15:31 Uhr tboeckel Posts: 124 Nutzer |
Zitat: Genau so, wie man es schon immer gemacht hat, nämlich mit FindHit aus dem Enforcer-Paket. Die nötigen Offsets werden auch im Crashlog mit angezeigt. Für GCC-compilierte Programme gibt GCCFindHit im Aminet. [ - Antworten - Zitieren - Direktlink - ] |
|
17.08.2009, 15:42 Uhr AGSzabo Posts: 1663 Nutzer |
@tboeckel: und das löppt unter os 4.1? eine lösung für e-uae (linux) wäre auch fantastisch. der uaeenforcer braucht windos. ich habe mal im aminet und os 4 depot geschaut und blos progs für 68k gefunden. die frage ist ob die im emulator genauso mächtig sind. -- Sam os4.1, e-uae 39bb2 - A4000d 39bb2 - Cyberst.MK3 060 50mhz 128mb - Cybervis. - Ariadne_II - ide DVD und 320gb HD (nur 128gb) - HD Floppy -- A500 3.1 adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110 [ - Antworten - Zitieren - Direktlink - ] |
|
17.08.2009, 18:51 Uhr Holger Posts: 8116 Nutzer |
Zitat:Klingt nach Problemen mit der Endianess. Der Autor der PNG-Laderoutine hat es richtig (portabel) gemacht, der Autor der IFF-Routine dagegen nicht. Wäre zumindest eine Möglichkeit. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
23.08.2009, 23:25 Uhr Reth Posts: 1858 Nutzer |
@Holger: Ja, das würde auch erklären, wieso die PC-Version von der Website anstandslos mit den Amiga-Daten funktioniert. Eine Konvertierung der entsprechenden Bilder nach JPEG brachte auch den Fehler nicht mehr. Dafür steigt das Programm nun aus, da es eines der Bilder in einem Format benötigt, das mit einer Palette arbeitet (SDL_Surface->format->palette darf nicht NULL sein)! Oh man! Dachte nicht, dass eine Portierung dermaßen ins Detail geht! Hier ist es wohl am besten das Ganze wieder Amiga-typisch zu machen, weg von SDL! Da weiss ich aber nicht, wie es mit der Verletzung von etwaigen Rechten, Eigentumsverhältnissen oder sonstigem aussieht, wenn man so etwas umsetzten will! Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
24.08.2009, 03:28 Uhr Andreas_Wolf Posts: 2980 Nutzer |
> Da weiss ich aber nicht, wie es mit der Verletzung von etwaigen > Rechten, Eigentumsverhältnissen oder sonstigem aussieht, wenn man so > etwas umsetzten will! Wieso sollte der Verzicht auf SDL da irgendwas dran ändern? [ - Antworten - Zitieren - Direktlink - ] |
|
24.08.2009, 17:11 Uhr ZeroG Posts: 1487 Nutzer |
@Reth: Wo befindet sich der Code zum Laden von ILBMs? Im Spielcode oder in einer der SDL linklibs? Suche am besten mal nach FORM, BODY und/oder BMHD. [ - Antworten - Zitieren - Direktlink - ] |
|
24.08.2009, 17:48 Uhr Reth Posts: 1858 Nutzer |
@ZeroG: Das Laden der Bilder erfolgt durch eine SDL-Routine kombiniert mit einer SDL-Image-Routine: C++ code:IMG_Load_RW(SDL_RWFromFile(filename, "rb"), 1); Das klappt für PNG und JPEG, aber anscheinen nicht für ILBM, da ich den genannten Fehler beim Freigeben innerhalb von SDL bekomme, wenn ich die originalen MegaLoMania ILBM-Bilder lade. Unter Windows auf einem X86-PC funktioniert das allerdings bestens, daher auch die Vermutung mit der Endianess. Wenn man das irgendwie eindeutig abgrenzen könnte, wäre das wohl ein Beitrag für die SDL-Image Buglist denke ich! Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
24.08.2009, 20:22 Uhr ZeroG Posts: 1487 Nutzer |
@Reth: Im OS4depot gibts 2x SDL_image 1.2.6 einmal von Spot portiert und einmal von Thomas Frieden. Welche Version benutzt du und was passiert wenn du die andere benutzt? [ - Antworten - Zitieren - Direktlink - ] |
|
25.08.2009, 18:29 Uhr Holger Posts: 8116 Nutzer |
Zitat:Dann konvertiere doch nach PNG, statt nach JPEG. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
07.09.2009, 15:38 Uhr Reth Posts: 1858 Nutzer |
@ZeroG: Habe zunächst 1.2.6 von Spot benutzt mit den bisher beschriebenen Problemen. Gestern hab ich dann mal die Version von Thomas Frieden probiert, zusammen mit den originalen Amiga-Grafiken (also keine JPegs). Dort gab es dann GRs innerhalb von SDL_Image-Klassen, die muss ich noch genauer untersuchen (glaub wieder bei ILBMs). So macht das keinen Spass! Anpassungen habe ich an anderen Stellen erwartet, nicht aber innerhalb von SDL bzw. bei der "Umgehung" von Problemen, die innerhalb von SDL auftreten! Aber ich sollte diese Thema eher im anderen Thread fortsetzen, in dem es direkt um die Portierung geht. Die Frage dieses Threads wurde ja beantwortet! Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
07.09.2009, 16:40 Uhr ZeroG Posts: 1487 Nutzer |
@Reth: Wenn du dir sehr sicher bist das der Fehler innerhalb von SDL, oder SDL_image liegt kannst du ja die jeweiligen Portierer anschreiben. [ - Antworten - Zitieren - Direktlink - ] |
|
08.09.2009, 08:57 Uhr Thore Posts: 2266 Nutzer |
In den Sourcen zu SDL_lbm.c hab ich Byteswap-Routinen gesehen. SDL_SwapBE16 und SDL_SwapBE32 werden verwendet wenn das entsprechende Endianess eingestellt ist. Schau mal im SDL Paket in der Datei SDL_endian.h und prüf ob eine der defines für Big Endianess zutrifft. Kannst ja mit einem Test rausfinden, was er einstellt. Wenn es fälschlicherweise LE zurückgibt, setz das define oder codier BE hart rein. Dann sollte es eigentlich klappen. [ - Antworten - Zitieren - Direktlink - ] |
|
18.10.2009, 22:23 Uhr Reth Posts: 1858 Nutzer |
@Thore: Also die ByteOrder steht auf SDL_BIGENDIAN zur Laufzeit, damit passt also das schon mal! Das k**zt mich jetzt echt gewaltig an! 0,0 Fortschritt, weil man bei so nem behämmertem Problem hängt und mit Logausgaben und addr2line nach Crashes im Dunklen rumtasten muss (es fehlt leider immer noch ein grafischer Sourcelevel-Debugger)! Habe keine Ahnung mehr, wo das Problem stecken könnte! Die letzte Stelle aus dem Fehlerprotokoll des GrimReaper zeigt auf: C++ code:SDL_pixels.c Zeile 538 Das Ganze tritt in der Image-Klasse von GigaLoMania auf, beim Aufruf von: C++ code:und zwar zum Bild mlm_select aus dem Amiga-Original! Kann evtl. mit libilbm zusammenhängen, da wenn ich JPegs verwende das Problem nicht auftritt.SDL_FreeSurface(this->surface); Allerdings kann ich nicht alle Bilder als jpegs verwenden, da einige "paletted" sein müssen (s. weiter oben im Thread). Daher habe ich mal eins davon in PNG konvertiert und siehe da: Dasselbe Problem mit PNG! GR mit demselben Problem an der selben Stelle in SDL_pixels.x Zeile 538!  (Wo ist der vor Wut explodierende Smilie, wenn man ihn braucht?!)Die PC-Version von GigaLoMania geht prima mit den Amiga-Originalgrafiken. Der Crash ist so schwer, dass nach dem Beenden den Programms aus dem GR heraus das ganze System einfriert, sobald man die nächste Aktion startet (mit der Maus was anklicken z.B.)! Vielleicht sollte ich das Thema aber in meinem anderen Thread weiterbehandeln, in dem es um SDL-Portierung geht. Das nervt total sowas! Ciao [ Dieser Beitrag wurde von Reth am 18.10.2009 um 23:00 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
19.10.2009, 18:15 Uhr Holger Posts: 8116 Nutzer |
Zitat:Was steht denn in dieser Zeile? -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
19.10.2009, 19:46 Uhr Reth Posts: 1858 Nutzer |
@Holger: Hab die Sourcen der SDL-Komponenten leider nicht mit installiert, müsste ich erst noch beschaffen (mal sehen, ob das so einfach nachträglich geht)! Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
24.10.2009, 19:07 Uhr Reth Posts: 1858 Nutzer |
Also ich hab die Sourcen zu SDL_Image für AOS4 weder in dem Archiv auf OS4Depot noch auf der SDL_Image Sourceforge Seite gefunden! Auch Google half hier noch nicht weiter! Hat jmd. ne Idee? Habe nur die Version von Richard Drummond von 2004 mit Source gefunden. Möchte eigentlich auch SDL-Komponenten nicht debuggen, sondern "nur" versuchen ein Spiel zu portieren. Bin von den Möglichkeiten zum Entwickeln auf dem PC halt echt verwöhnt und begeistert, auf dem Amiga quält man sich leider immer nur voran und hat an manchen Stellen keine Chance weiter zu kommen (auch wegen fehlender Tool-Unterstützung)! Merk schon wieder, dass ich wütend werde, sollte daher erst mal was anderes machen! Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
24.10.2009, 19:36 Uhr ZeroG Posts: 1487 Nutzer |
@Reth: Ich glaub nicht das an dem Quelltext von SDL_image irgendwelche großen änderungen gemachten wurden (wenn überhaupt) Die aktuelle Version gibts da: http://www.libsdl.org/projects/SDL_image/ [ - Antworten - Zitieren - Direktlink - ] |
|
24.10.2009, 19:57 Uhr Reth Posts: 1858 Nutzer |
@ZeroG: Die hab ich auch gefunden, nicht aber den Source zu der OS4-Version, die ich gerade verwende. Und mich darauf verlassen, dass die Quellen identisch sind möchte ich eigentlich nicht! Gibts den Source der aktuellen Version denn auch irgendwo nicht im rpm-Format? [ Dieser Beitrag wurde von Reth am 24.10.2009 um 19:58 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
26.10.2009, 16:45 Uhr ZeroG Posts: 1487 Nutzer |
@Reth: Normalerweise dürfte da nichts oder nicht viel zu ändern sein, das Ding hat schließlich Spot portiert und der sagt von sich selbst das er ein programmier Noob ist. Versuch einfach mal einen configure/make lauf und guck was passiert. Zitat:  Auf der Seite die ich verlinkt hab gibts den Source zur aktuellen 1.2.8 als tar.gz .rpm und .zip.Da hast du dich aber ganz schön angestrengt das zu übersehen  [ - Antworten - Zitieren - Direktlink - ] |
|
27.10.2009, 09:31 Uhr Reth Posts: 1858 Nutzer |
Zitat: Allerdings (Augen reib)! [ - Antworten - Zitieren - Direktlink - ] |
|
14.12.2009, 20:45 Uhr Reth Posts: 1858 Nutzer |
Zitat: Klappt leider nicht! In der sh kommen bei configure u.a. folgende Meldungen (hab auch noch den ganzen Output), die rm-Fehler betrachte ich mal als harmlos, ebenso die Warnings. Die letzten Meldungen sind wohl die eigentliche Problemursache vermute ich: C code: Make meint daraufhin nur trocken: C code:Makefile:408: .deps/IMG.Plo: No such file or directory Makefile:409: .deps/IMG_ImageIO.Plo: No such file or directory Makefile:410: .deps/IMG_bmp.Plo: No such file or directory Makefile:411: .deps/IMG_gif.Plo: No such file or directory Makefile:412: .deps/IMG_jpg.Plo: No such file or directory Makefile:413: .deps/IMG_lbm.Plo: No such file or directory Makefile:414: .deps/IMG_pcx.Plo: No such file or directory Makefile:415: .deps/IMG_png.Plo: No such file or directory Makefile:416: .deps/IMG_pnm.Plo: No such file or directory Makefile:417: .deps/IMG_tga.Plo: No such file or directory Makefile:418: .deps/IMG_tif.Plo: No such file or directory Makefile:419: .deps/IMG_xcf.Plo: No such file or directory Makefile:420: .deps/IMG_xpm.Plo: No such file or directory Makefile:421: .deps/IMG_xv.Plo: No such file or directory Makefile:422: .deps/showimage.Po: No such file or directory gmake: *** No rule to make target '.deps/showimage.Po'. Stop. Völlig vertändlich! Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
15.12.2009, 17:47 Uhr ZeroG Posts: 1487 Nutzer |
@Reth: Versuch mal das überprüfen der abhängigkeiten abzuschalten. configure --disable-dependency-tracking make EDIT: Fast vergessen: Zitat: Stell sicher das libjpeg und die Header dazu richtig installliert sind. [ Dieser Beitrag wurde von ZeroG am 15.12.2009 um 17:48 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
| -1- | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Programmierung > Wie aus GrimReaper Protokoll auf Ursache im Code zurückfinden? | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|