Debug (progr. Morphos)

12 sujets de 1 à 12 (sur un total de 12)

anonyme
24 février 2005 à 23h30 #1462
hello

J’ai un petit souci en ce moment sur mon programme…

De temps en temps en sortie de programme voici le bug que j’obtiens :

ASM_Exception: DAR 0xdeadfab1 DSISR 0x42000000

ASM_Exception: IntGPR1 0x1002fc0 SRR0 0x10142868 SRR1 0x7030 LR 0x10142830

ASM_Exception: Type 0x3

ASM_Exception: Thread 0x57b9e0 Name Emul: Time

ASM_Exception: DAR 0xdeadfab1 DSISR 0x42000000

ExceptionThread: Exception Thread 0x57b9e0 (Emul: Time)

ExceptionThread: Type 0x3 (Data Access)

ExceptionThread: Illegal Data Access at 0xdeadfab1 DSISR 0x42000000 (Write Access to a not existing Page)

PC(SRR0) 0x10142868 MSR(SRR1) 0x00007030

CR 24000000 XER 20000000 LR 10142830 CTR 00418758 General Register

Dump: GPR[0] 0057d4a0 20029650 20029b94 0000b030 00000001 0043a2c8

20027afe 20027afa GPR[8] 21245c38 0000f030 2117b170 deadfaad 00007030

0d0d0d0d 0e0e0e0e 0f0f0f0f GPR[16] 10101010 20029678 20029ae8 00000001

00000000 0000001f 20029b10 20027ae2 GPR[24] 20027afe 20027ade 20027afa

0057d4a0 21245c38 40000000 00000000 200278bc FPSCR 00000000 FPECR

00000000 FPR[0] 0x0000000020020001 0x0000000000000000

0x0000000000000000 0x0000000000000000 FPR[4] 0x0000000000000000

0x0000000000000000 0x0000000000000000 0x0000000000000000 FPR[8]

0x0000000000000000 0x0000000000000000 0x0000000000000000

0x0000000000000000 FPR[12] 0x0000000000000000 0x0000000020020001

0x0000000000000000 0x0000000000000000 FPR[16] 0x0000000000000000

0x0000000000000000 0x0000000000000000 0x0000000000000000 FPR[20]

0x0000000000000000 0x0000000000000000 0x0000000000000000

0x0000000000000000 FPR[24] 0x0000000000000000 0x0000000000000000

0x0000000000000000 0x0000000000000000 FPR[28] 0x0000000000000000

0x0000000000000000 0x0000000000000000 0x0000000000000000 Special

Register Dump:

IABR 00000000 DABR 00000000

PCM1 00000000 PMC2 00000000 PMC3 00000000 PMC4 00000000 OS Register

Dump:

SysCall_SRR0 101457b8 SysCall_SRR1 00007030 SysCall_GPR2 20029b94

SysCall_LR 0d0d0d0d SysCall_CR 10142830

StackFrame History:

Stack 0x20029650 StackEnd 0x20029b8c LR 0x10142830

ASM_Exception: DAR 0x20029650 DSISR 0x40000000

ASM_Exception: IntGPR1 0x1002fc0 SRR0 0x41d2a8 SRR1 0x3030 LR 0x41d28c

ASM_Exception: Type 0x3

ASM_Exception: Thread 0x144d030 Name Exception Server

ASM_Exception: DAR 0x20029650 DSISR 0x40000000

Quelqu’un pourrait m’indiquer la marche à suivre pour eviter ce désagrement SVP ?? (par où commencer, etc…) en vue d’éradiquer ce bug… parce que là je suis paumé

NDBatteMan : J’ai enlevé quelques “—” qui cassaient la mise en page.
stan
25 février 2005 à 0h17 #33001
Deux possibilités : mettre des messages de debug partout dans ton prog (kprintf()) pour voir entre quels messages de debug ça hitte, ou utiliser objdump pour localiser l’instruction qui hitte.

Pour utiliser kprintf(), il faut linker avec libdebug.a qui est dans le répertoire /ppc-morphos/lib/libnix/ du SDK (donc, pour gcc, -ldebug -noixemul fait l’affaire).

Pour objdump, c’est expliqué dans l’article de Henes sur http://www.biclodon.com .

Je résume, en français : il faut taper objdump –reloc –disassemble-all tonexe >tonexe.dump

Ensuite tu charges tonexe.dump dans ton éditeur et tu cherches le SRR0 (dans ton cas, 10142868).

Il faut avoir compilé ton exe avec -g (que ce soit avec gcc ou vbcc) pour avoir les noms des fonctions dans le dump, ce qui te permettra de t’y retrouver.

Avec un peu de chance, je ne me suis pas planté dans l’explication.

PS : t’es pas sympa avec Fab1
anonyme
25 février 2005 à 5h54 #33002
@stan

ok et merci pour tes explications …

PS: c’est vrai que DeadFab1 ca le fait pas
anonyme
25 février 2005 à 6h07 #33003
@stan:

J’ai fait comme tu m’as indiqué( objdump, editeur, recherche de 10142868, etc…), mais y a un probleme… 10142868 ben ca n’y est pas dans le dump.
henes
25 février 2005 à 14h49 #33004
Il ne s’agit pas du crash d’une tache/process exec.library comme pourrait l’être “ide.device” ou “bourriquet”. D’ailleurs, il n’y a pas de partie “Running Task”.

Il s’agit du crash du thread “Emul: Time” de l’ABox.

De ce fait, le dump présent dans le log n’a pas été fait par le gestionnaire d’exception d’exec.library (puisqu’il ne s’agit pas d’une exception causée par une tache/process qu’il gère) mais par celui de l’ABox.

Cela se passe donc à un niveau supérieur à exec.library et au reste de l’environnement amiga classique.

Inutile donc de chercher des informations de segment telles que fournies par segtracker pour ensuite trouver un offset dans bourriquet ou autre. Ce thread “Emul: Time” n’a de toute façon probablement jamais été exécuter du code de bourriquet.

Il y a de nombreuses raisons qui pourraient expliquer le crash de ce thread: bourriquet trashant sa mémoire, etc…

Néanmoins, le fait que l’accès mémoire illégal se fasse en 0xdeadfab1 donne un indice intéressant. On peut même voir que le registre r11 (GPR[11] dans le dump) contient 0xdeadfaad et qu’il doit donc s’agir d’un accès relatif à cette adresse.

Hors, exec.library/DeleteIORequest() rempli iorequest->io_Message.mn_Node.ln_Succ avec ce motif 0xdeadfaad. C’est probablement spécifique à l’exec.library de MorphOS et fait pour faire crasher le plus vite possible les applis buguées.

On peut imaginer qu’un iorequest est réutilisé après avoir été “deleteiorequesté”.

Puisque c’est le thread “Emul: Time” qui crash, on peut imaginer qu’il s’agit d’un thread relatif au temps (“time”) et utilisé par le timer.device

Peut-être un couple de AbortIO()+WaitIO() a été oublié avant le DeleteIORequest() d’un iorequest envoyé au timer.device.
anonyme
25 février 2005 à 20h54 #33005
@henes:

Cool

Pour du debug ca c’est un petit cours de derriére les fagots pour debugger vite fait bien fait…
henes
3 mars 2005 à 21h10 #33006
C’était ça ou pas ?
henes
20 mars 2005 à 18h25 #33007
Deux semaines plus tard…
anonyme
20 mars 2005 à 18h44 #33008
@henes: oups… je t’avais oublié

pas bien de ma part

oui c’etait bien ca… un probleme de timer… depuis j’ai résolu le probléme

encore désolé pour le retard de la réponse
henes
24 mars 2005 à 15h18 #33009
Pas grâve, l’important est de répondre

STP, peux tu me dire si tu avais le bug exact que j’ai décrit: AbortIO/WaitIO manquant. Dans le cas contrairee, pourrais tu rapidement me décrire ce qui causait le problème ?

Il est important pour moi de savoir s’il existe différentes manière de reproduire ce genre de log.

Merci.
anonyme
26 mars 2005 à 20h39 #33010
@henes:

Bon… mon probléme venait du timer… ca tout le monde a pu le lire , mais dans bourriquet, le seul timer que j’ai mis en place se situe dans la tache qui pilote la connexion générale sur un serveur…

Donc résultat, comme ce big bug se situait non pas dans bourriquet mais dans l’abox, j’ai mis en place un autre timer qui démarre dés le lancement de bourriquet… (ce second timer mis en place est pompé sur les sources de YAM… ) résultat plus de bug

Enfin, j’espére que j’ai été trés clair… sinon, y aura bientôt les sources complétes de bourriquet (version 0.2. disponibles sur http://www.bourriquet-project.org/fr/downloads.html pour voir ce que j’ai fait…
henes
1 avril 2005 à 16h59 #33011
Mais est ce qu’il te manquait un couple de WaitIO/AbortIO() ? :-p