Posté le 28/10/2020 18:57
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 119 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
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.
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...
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.
Citer : Posté le 28/10/2020 19:16 | #
Ah! ça complique encore plus !
On continue, alors : TARGET = 35343433
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)
Citer : Posté le 28/10/2020 19:18 | #
En vrai ?
Comment c'est possible ?
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
Citer : Posté le 28/10/2020 19:22 | #
Sûrement un traitement d'un int en int* ?
Ecrivez vos programmes basic sur PC avec BIDE
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)
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.
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*
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...
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.
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..
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)
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é.
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.
Citer : Posté le 29/10/2020 12:06 | #
Merci beaucoup pour les explications !
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à ?
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.
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 !
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).