Les membres ayant 30 points peuvent parler sur les canaux annonces, projets et hs du chat.
La shoutbox n'est pas chargée par défaut pour des raisons de performances. Cliquez pour charger.

Forum Casio - Autres questions


Index du Forum » Autres questions » Comment déchiffer un "System Error"
Darkjura Hors ligne Membre Points: 389 Défis: 0 Message

Comment déchiffer un "System Error"

Posté le 28/10/2020 18:57

Bonsoir !
Comme l'indique le titre, existe-t-il un moyen de déchiffrer un system error survenu pendant l'exécution d'un add-in, par exemple pour savoir où et pourquoi le programme s'est planté ?
Dans mon cas, ça vient d'arriver pendant le test d'un jeu d'échecs multijoueur (avec le câble 3-pin) en préparation. Du coup, j'aimerai bien pouvoir situer l'erreur... Je vous ai mis une capture d'écran de l'erreur en question (effectuée à l'aide du Screen Receiver)
Merci d'avance !

Moi

Fichier joint


Lephenixnoir En ligne Administrateur Points: 24146 Défis: 170 Message

Citer : Posté le 28/10/2020 19:01 | #


Yup, alors le plus important c'est PC : l'adresse dans la mémoire où se trouve l'instruction qui a provoqué l'erreur. Selon comment l'add-in a été compilé (fx-9860G SDK ou avec GCC) tu peux généralement retrouver la fonction dans laquelle cette instruction se trouve.

Pour les TLB miss (en gros : accès à de la mémoire inexistante), une autre information utile est TARGET, l'adresse à laquelle le programme a tenté d'accéder mais qui n'existe pas.

Parfois les valeurs affichées sont complètement garbage et j'ai aucune idée de pourquoi donc dans certains scénarios il n'y a aucune information utilisable, ne me demande pas pourquoi (corruption de pile ?). Ici tes infos ont l'air assez garbage.

Si tu développes avec le SDK, ce super vieux topic peut t'être vaguement utile.
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Darkjura Hors ligne Membre Points: 389 Défis: 0 Message

Citer : Posté le 28/10/2020 19:05 | #


Je développe avec le SDK
C'est vrai que ça a l'air chelou
Et donc, avec PC = 0000001E, tu arriverais à en tirer quelque chose ?

Je regarde le topic aussi.

Ajouté le 28/10/2020 à 19:13 :
J'ai lu, mais c'est assez brumeux...
Kbd2 Hors ligne Membre Points: 269 Défis: 0 Message

Citer : Posté le 28/10/2020 19:13 | #


PC = 0000001E is useless, as the addin starts at PC = 00300000 and most system functions at PC >= 80000000.
Darkjura Hors ligne Membre Points: 389 Défis: 0 Message

Citer : Posté le 28/10/2020 19:16 | #


Ah! ça complique encore plus !

On continue, alors : TARGET = 35343433
Lailouezzz Hors ligne Membre Points: 91 Défis: 0 Message

Citer : Posté le 28/10/2020 19:17 | #


Ahah TARGET = 35343433 c'est étrange car c'est ni dans la ROM ni dans la RAM x)
Darkjura Hors ligne Membre Points: 389 Défis: 0 Message

Citer : Posté le 28/10/2020 19:18 | #


En vrai ?
Comment c'est possible ?
Lailouezzz Hors ligne Membre Points: 91 Défis: 0 Message

Citer : Posté le 28/10/2020 19:21 | #


Perso je ne saurais pas interpréter le PC = 0000001E car c'est dans le BIOS logiquement donc je saurais pas dire
Zezombye Hors ligne Rédacteur Points: 1756 Défis: 13 Message

Citer : Posté le 28/10/2020 19:22 | #


Sûrement un traitement d'un int en int* ?
Divers jeux : Puissance 4 - Chariot Wars - Sokoban
Ecrivez vos programmes basic sur PC avec BIDE
Lailouezzz Hors ligne Membre Points: 91 Défis: 0 Message

Citer : Posté le 28/10/2020 19:22 | #


après je sais pas si tu peux envisager de faire un mode loggé de ton add in en utilisant B-File (j'ai programmé très peu d'add-in j'ai juste RE donc à confirmer si c'est envisageable)
Kbd2 Hors ligne Membre Points: 269 Défis: 0 Message

Citer : Posté le 28/10/2020 19:22 | #


A jump to 0x1E indicates something very wrong with the code, e.g. calling a function pointer that is NULL.
Lailouezzz Hors ligne Membre Points: 91 Défis: 0 Message

Citer : Posté le 28/10/2020 19:23 | #


Justement oui je me disais c'est surement une erreur read d'un pointeur non initialisé ou un traitement de int en int*
Darkjura Hors ligne Membre Points: 389 Défis: 0 Message

Citer : Posté le 28/10/2020 19:24 | #


Par contre désolé mais je n'y connais ABSOLUMENT rien en adresses/OS/BIOS/ROM/RAM
J'aimerais juste savoir d'où vient ce bug qui m'handicape depuis ce midi...

Ajouté le 28/10/2020 à 19:26 :
... Le traitement de int en *int, ça me paraît tout à fait possible...
Je crois que j'ai une piste
Je vérifie...
Lailouezzz Hors ligne Membre Points: 91 Défis: 0 Message

Citer : Posté le 28/10/2020 19:27 | #


Oui désolé de t'avoir parlé de ça (adresses de ROM RAM etc) mais check comment tu gères les pointeurs.
Darkjura Hors ligne Membre Points: 389 Défis: 0 Message

Citer : Posté le 28/10/2020 19:32 | #


...Eh bien, il ne me semble pas voir la moindre erreur, en fait.
J'ai vérifié les deux seules variables de type 'int' que mon programme utilisait.
Je pense que ça doit être au niveau de Serial_WriteByte() ou Serial_ReadByte(), mais il ne me semble pas voir aucune erreur...

Ajouté le 28/10/2020 à 19:34 :
...Mais évidemment !!!!!
Serial_WriteByte() gère...les chars !!!!!!
Pas les int !!!!!!!!

J'essaye de changer, je reviens

Ajouté le 28/10/2020 à 19:42 :
Ca marche !!!!!!!!!!!!!!!!!!

............À cause d'une erreur de 'int' ?!!

Du coup c'est trop cool..

Pub : ne manquez pas ce superbe jeu qui sortira d'ici 2/3 jours

Je vous demande juste : comment vous avez fait pour savoir que le problème venait d'un type 'int' mal utilisé ? (allez-y, c'est pas grave, j'essayerais de comprendre)
Lephenixnoir En ligne Administrateur Points: 24146 Défis: 170 Message

Citer : Posté le 28/10/2020 21:42 | #


L'hypothèse selon laquelle un int peut avoir été pris pour un pointeur est assez simple. Tu vois, les pointeurs ils ont toujours des valeurs assez grandes (0x00300000, 0x80000000, tous ces machins-là valent plusieurs millions sinon plusieurs milliards). Or la valeur indiquée pour PC est 0x1e = 30, une toute petite valeur, quelque chose qui n'a aucun sens en tant que pointeur.

Si tu accèdes à l'adresse 30, il est naturel de penser que peut-être tu avais une variable qui valait 30 et que tu as envoyé cette variable à une fonction qui attendait un pointeur (ce qui génère un warning que tu ne vois pas forcément passer à la compilation), et la fonction a tenté d'utiliser le pointeur, et paf ça fait des System Chocapic.

Mais ça c'est une théorie valide que si tu accèdes à une donnée à une adresse qui ressemble à un entier. Ici c'est ton PC. La différence c'est que le PC, qui représente l'endroit du programme que tu es en train d'exécuter, pointe vers du code. Et dans un programme tu manipules très peu voire pas du tout de pointeurs vers du code. Tu manipules des pointeurs vers des données oui (des entiers, du texte, des images, etc), mais du code très rarement et quand tu le fais y'a pas vraiment de risque d'erreur comme ça.

Ici en plus l'erreur c'est ADDRESS (R) ce qui signifie un accès à des données. Non seulement la System ERROR prétend qu'une erreur s'est produite durant l'exécution du code à l'adresse 0x1e mais en plus elle prétend que ce code marche très bien et que c'est un accès en données durant l'instruction qui s'est mal passé. Par un heureux hasard il y a bien du code à 0x1e mais c'est le bootcode et je vois pas trop comment tu aurais pu sauter là (à part sauter à NULL) ? Et même dans le bootcode y'a aucune raison de faire apparaître 35343433.

Parfois la valeur est juste du bullshit et il faut l'accepter. Je sais par expérience que durant une System ERROR l'OS va lire les valeurs de SPC et TEA dans le stack frame du gestionnaire d'exceptions avec un offset fixe dans la pile, un truc un peu malsain. Si l'offset est faux les valeurs affichées n'auront rien à voir avec la vérité.

Serial_WriteByte() gère...les chars !!!!!!
Pas les int !!!!!!!!

La promotion des arguments fait que quoi qu'il se passe, c'est un entier complet qui arrive à Serial_WriteByte(). En particulier déclarer la variable que tu lui envoies comme char au lieu de int n'a aucun effet, à part couper la valeur à 8 bits. Peut-être qu'il est confus si tu lui donnes une valeur de plus de 8 bits mais c'est douteux.
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Darkjura Hors ligne Membre Points: 389 Défis: 0 Message

Citer : Posté le 29/10/2020 12:06 | #


Merci beaucoup pour les explications !

Lephenixnoir a écrit :
La promotion des arguments fait que quoi qu'il se passe, c'est un entier complet qui arrive à Serial_WriteByte().

En fait je me suis mal exprimé. Je pense que l'erreur a eu lieu dans Serial_ReadByte() : j'envoie à la fonction un pointeur sur int, alors qu'elle attendait un pointeur sur char. Est-ce que la question des 8 bits est plus compliquée dans ce cas-là ?
Lephenixnoir En ligne Administrateur Points: 24146 Défis: 170 Message

Citer : Posté le 29/10/2020 13:05 | #


Oui ! De plusieurs façons ! Sans aller dans les détails sordides d'alignement, un char fait 8 bits et un int fait 32 bits (sur cette architecture). Donc Serial_ReadByte(), quoi que tu fasses, ne modifie que 8 bits de mémoire. Si tu as créé un int, seule une partie des bits de l'int sera donc affectée, l'autre partie restera à sa valeur initiale. Déjà tu sens que ça peut pas très bien se passer.

En plus de ça, quand tu es en big-endian, l'ordre des octets dans un int c'est le plus gros d'abord. Si tu veux tu peux voir un int comme un nombre en décimal à 4 chiffres genre 2749, et un char comme un nombre à 1 chiffre genre 5. Ici si tu passes un pointeur vers ton 2749 à Serial_ReadByte(), il va écrire un octet et lui donner la valeur 5, et tu te retrouves avec l'int 5749 au lieu de 0005. Donc le résultat est complètement faux.
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Darkjura Hors ligne Membre Points: 389 Défis: 0 Message

Citer : Posté le 29/10/2020 13:08 | #


D'accord ! C'est logique, en fait.
Merci beaucoup, et à bientôt sur la page du programme en question !
Lephenixnoir En ligne Administrateur Points: 24146 Défis: 170 Message

Citer : Posté le 29/10/2020 13:13 | #


Résumé pour ceux qui veulent pas tout lire : passer des char/short/int à des fonctions, tout ça revient au même. Mais si c'est des pointeurs, tout de suite on déconne plus ! Faut que les types correspondent exactement (d'ailleurs y'a des warnings si vous le faites pas).
Mon graphe (24 Mars): (gint#27 ; (Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)

LienAjouter une imageAjouter une vidéoAjouter un lien vers un profilAjouter du codeCiterAjouter un spoiler(texte affichable/masquable par un clic)Ajouter une barre de progressionItaliqueGrasSoulignéAfficher du texte barréCentréJustifiéPlus petitPlus grandPlus de smileys !
Cliquez pour épingler Cliquez pour détacher Cliquez pour fermer
Alignement de l'image: Redimensionnement de l'image (en pixel):
Afficher la liste des membres
:bow: :cool: :good: :love: ^^
:omg: :fusil: :aie: :argh: :mdr:
:boulet2: :thx: :champ: :whistle: :bounce:
valider
 :)  ;)  :D  :p
 :lol:  8)  :(  :@
 0_0  :oops:  :grr:  :E
 :O  :sry:  :mmm:  :waza:
 :'(  :here:  ^^  >:)

Σ π θ ± α β γ δ Δ σ λ
Veuillez donner la réponse en chiffre
Vous devez activer le Javascript dans votre navigateur pour pouvoir valider ce formulaire.

Si vous n'avez pas volontairement désactivé cette fonctionnalité de votre navigateur, il s'agit probablement d'un bug : contactez l'équipe de Planète Casio.

Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 131 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements

Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd