Boo
./1
Lepzulnag - Posté le 08/11/2011 à 12:47 - Edité par Lepzulnag le 08/11/2011 à 15:28 Membre depuis le 29/06/2010, 26 messages
Bonjour !

Voilà je suis actuellement en train de programmer un logiciel de dessin qui marche plutôt bien, et en voulant améliorer la vitesse de mon affichage, je suis tombé sur un bug que je ne comprends pas.

Les symptômes

Lorsque mon programme tourne, un appui sur la touche ON met automatiquement le contraste à 0.
Lorsque je quitte mon programme sans appuyer sur la touche ON, et ensuite appuie sur la touche ON (alors que je navigue sur l'interface basique de ma TI), le contraste est mis à 0. Le bug de contraste est plus fort que la commande OFF : si j'essaie d'éteindre ma calculette, il ne l'éteindra pas, mais mettra le contraste à 0.

Le bug ne frappe qu'une fois; un deuxième appui sur la touche ON ne modifiera pas le contraste et je peux l'éteindre normalement.

EDIT : De plus, la mémoire Flash ROM Free affichée dans le menu mem de la calculette affiche la quantité 2 une fois le programme quitté.


Le code foireux

J'ai évidemment recherché dans mon programme la/les lignes de code à la source du mystérieux problème, et suis finalement tombé avec surprise sur cet innocent bout de code :

for (x=0;x<160;x++) memcpy(LCD_MEM+30*x, virtual+20*x, 20);

où virtual est un buffer de 2000 octets (soit un plein écran de ti89). Cette ligne (qui marche parfaitement à l'exécution) affiche à l'écran l'image enregistrée dans virtual.

Or lorsque je la mets en commentaire, je ne retrouve plus le bug de contraste ! Et je ne vois pas le rapport entre la touche ON, un contraste mis à zéro, et ce bout de code... #confus#


Je précise également que je désactive (plus exactement redirige vers rien) les auto-int 1 et 5 au début de mon programme, et les réactive à la fin.



Comment et surtout pourquoi ma calculette réagit-elle de la sorte ? Si quelqu'un a une idée, cela m'aiderait beaucoup.
./2
Uther - Posté le 08/11/2011 à 13:34 Membre depuis le 10/06/2001, 6799 messages
Si je me souviens bien la touche ON déclenche l'auto-int 6, donc, je dirais que tu dois avoir modifié cet auto-int par erreur, ce qui expliquerait également pourquoi le problème persiste une fois le programme terminé.

Par contre, j'ai du mal a voir un éventuel rapport avec la ligne que tu as posté.
avatar
./3
Folco - Posté le 08/11/2011 à 14:35 Membre depuis le 18/06/2001, 29790 messages
Tu peux installer PreOS et regarder sir le big persiste ?
avatar <<< Kernel Extremist©®™ >>>
Saint Qt, priez pour nous.
./4
Lepzulnag - Posté le 08/11/2011 à 15:22 - Edité par Lepzulnag le 08/11/2011 à 15:27 Membre depuis le 29/06/2010, 26 messages
Bon, il y a du nouveau ! smile

J'ai vérifié, je n'ai pas touché à l'auto-int 6 à cause d'une quelconque faute de frappe. Cependant je le modifie peut-être d'une manière plus sournoise et involontaire. C'est une piste...

J'ai installé PreOS v1.0.7 et le bug persiste.

J'ai découvert un nouveau symptôme ! Une fois le programme quitté, la quantité de mémoire flash ROM free affichée dans le menu mem de la calc devient égale à 2 ! (premier message édité)
(ce bug est de plus en plus mystérieux... ah, le C ! grin )

Peut-être un buffer overflow ? Ce serait en rapport avec la ligne de code qui fait bugger, mais elle me semble parfaite.

En fait, ce qui m'embête vraiment, c'est que c'est FORCEMENT le memcpy qui fait bugger, puisque tout marche quand je le mets en commentaire, et pourtant c'est impossible puisque c'est une boucle on ne peut plus simple et qui a de surcroît le culot de marcher... #pleure#

Il faudrait trouver les causes possibles des symptômes observés, et voir lesquels sont susceptibles d'être présent dans mon programme.

J'utilise PortSet pour des images 159x99 (et non 239x127), les auto-int 1 et 5, et j'écris parfois directement sur la mémoire vidéo. Y a-t-il dans ces manipulations quelque piste?
./5
Pen^2 - Posté le 08/11/2011 à 15:27 - Edité par Pen^2 le 08/11/2011 à 15:53 Membre depuis le 10/06/2001, 30231 messages
Es-tu sûr de ne pas dépasser ? Il me semble qu'il y a des variables systèmes derrière la mémoire vidéo.
./6
Lepzulnag - Posté le 08/11/2011 à 15:36 Membre depuis le 29/06/2010, 26 messages
OUIIIIIII !!! #oui# #oui# #oui# #oui# #oui#

Merci Pen^2 !!!

J'étais fatigué, et finalement tout est bien qui finit bien : c'est bien le memcpy qui faisait bugger !

J'avais juste inversé les lignes et les colonnes. Le bon code est :
for (x=0;x<100;x++) memcpy(LCD_MEM+30*x, virtual+20*x, 20);



Et dire que personne n'avait remarqué la petite erreur dans cette petite ligne de code grin

Je vous remercie tous et vous souhaite une bonne journée smile
./7
Uther - Posté le 08/11/2011 à 15:43 Membre depuis le 10/06/2001, 6799 messages
edit: crosspost
avatar
./8
squalyl - Posté le 08/11/2011 à 15:50 Membre depuis le 16/06/2001, 59730 messages
rah le bug qui tue, on aurait pu y passer des jours grin

le buffer d'écran n'est pas contigu? t'avais pas moyen de faire l'opération en un seul memcpy de la bonne taille?
./9
Brunni - Posté le 08/11/2011 à 15:58 Membre depuis le 03/11/2002, 11548 messages
J'avais pas vu non plus ^^
En fait quand tu suspectes un buffer overflow, le mieux à faire est de réduire la zone de mémoire affectée et observer le changement. Par exemple, tu aurais remplacé 160 par 80 et tu te serais aperçu que ce n'est pas la moitié de l'écran qui s'efface alors mais plus du trois quart. wink

squalyl> Le buffer fait 240 de large wink
avatar Avatar fait avec GIMP. Parce que les outils libres ça peut servir à autre chose que casser les pieds aux autres.

"La vie est un grand terrain de jeu. On le sait quand on est enfant mais on l’oublie en grandissant."

http://www.mobile-dev.ch/
Lepzulnag - Posté le 08/11/2011 à 16:10 Membre depuis le 29/06/2010, 26 messages
Comme quoi parfois on a beau avoir la solution devant le nez, on se refuse à voir l'erreur smile

J'ai choisi un buffer virtuel de 160x100, celui de la mémoire vidéo étant de 240x128, tous les 20 octets suivent 10 octets totalement inutiles pour la ti-89.
Lepzulnag - Posté le 08/11/2011 à 16:13 Membre depuis le 29/06/2010, 26 messages
Brunni > C'est ce que j'avais fait, mais avec un nombre encore trop grand...
Folco - Posté le 08/11/2011 à 17:26 Membre depuis le 18/06/2001, 29790 messages
Lepzulnag (./4) :
J'ai vérifié, je n'ai pas touché à l'auto-int 6 à cause d'une quelconque faute de frappe. Cependant je le modifie peut-être d'une manière plus sournoise et involontaire. C'est une piste...

Pour info, il y a une protection matérielle pour empêcher d'écrire dans la zone des vecteurs (les 100 ou $100 premiers octets, je sais plus). Et le handler de l'AI6 est en flash, donc il y a un risque ultra minime que ça puisse arriver.
Lepzulnag (./4) :
J'ai installé PreOS v1.0.7 et le bug persiste.

Ca voulait dire que le handler de l'AI6 n'était pas en cause, ce qui est bien le cas.
Lepzulnag (./4) :
et pourtant c'est impossible

Pour ta gouverne : fous-toi à grand coup de massue dans le crâne qu'un bug, c'est TOUJOURS !!! de ta faute. Si tu pars avec une autre mentalité, tu seras frustré. J'en ai fait l'expérience avant de l'admettre, ou d'avoir un niveau assez bon pour trouver les bugs des autres. cheeky
Pen^2 (./5) :
Il me semble qu'il y a des variables systèmes derrière la mémoire vidéo.

Yep, et la pile superviseur avant. Mieux vaut bien viser ^^
Et pour info, PreOS sauvegarde/restaure 3 lignes sous l'écran pour éviter une partie des désagréments. smile
avatar <<< Kernel Extremist©®™ >>>
Saint Qt, priez pour nous.
Pen^2 - Posté le 08/11/2011 à 17:29 Membre depuis le 10/06/2001, 30231 messages
Quel coquin ce PreOS ##modui##
Lionel Debroux - Posté le 08/11/2011 à 18:49 Membre depuis le 28/10/2001, 7564 messages
Si tu as recours à un buffer virtuel de 20 octets de large, c'est que tu utilises les fonctions d'AMS et que tu n'as pas besoin de vitesse smile
Les librairies graphiques rapides utilisent des buffers pleine taille et de la copie rapide.
avatar Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
Pen^2 - Posté le 08/11/2011 à 18:55 Membre depuis le 10/06/2001, 30231 messages
(Tu devrais lui dire quelle est la bibliothèque graphique la plus efficace ; perso je ne suis plus très au courant)
Brunni - Posté le 08/11/2011 à 19:03 Membre depuis le 03/11/2002, 11548 messages
C'était pas extrgraph? smile
avatar Avatar fait avec GIMP. Parce que les outils libres ça peut servir à autre chose que casser les pieds aux autres.

"La vie est un grand terrain de jeu. On le sait quand on est enfant mais on l’oublie en grandissant."

http://www.mobile-dev.ch/
Lionel Debroux - Posté le 08/11/2011 à 20:42 Membre depuis le 28/10/2001, 7564 messages
Il n'est pas obligé d'utiliser une librairie graphique s'il n'en a pas besoin smile

En 2011, il n'y a que deux librairies graphiques (quelque peu) maintenues: ExtGraph et Genlib. Elles ne sont pas vraiment en concurrence (librairie statique vs. librairie dynamique), et Genlib a été une source d'inspiration pour ExtGraph à plusieurs reprises smile
avatar Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
Lepzulnag - Posté le 09/11/2011 à 08:58 Membre depuis le 29/06/2010, 26 messages
En effet je n'utilise pas de librairie graphique. Ayant commencé à programmer en TI-basic, et ne programmant rien nécessitant une grande vitesse d'exécution, je m'extasiais régulièrement sur la rapidité des fonctions de l'AMS tongue

Mais à présent que je m'attaque à des outils graphiques plus complexes, je commence à utiliser extgraph (et là l'extase atteint son paroxysme smile ).
Folco - Posté le 09/11/2011 à 09:59 Membre depuis le 18/06/2001, 29790 messages
Et bien, qu'est-ce que ça sera devant Genlib. happy
avatar <<< Kernel Extremist©®™ >>>
Saint Qt, priez pour nous.
Lepzulnag - Posté le 12/11/2011 à 13:08 Membre depuis le 29/06/2010, 26 messages
Je meurs?

Genlib, la librairie qui tue.
Folco - Posté le 12/11/2011 à 13:59 Membre depuis le 18/06/2001, 29790 messages
grin
avatar <<< Kernel Extremist©®™ >>>
Saint Qt, priez pour nous.
Pen^2 - Posté le 12/11/2011 à 14:12 Membre depuis le 10/06/2001, 30231 messages
(c'est une bibliothèque tongue)
Folco - Posté le 12/11/2011 à 14:20 Membre depuis le 18/06/2001, 29790 messages
Eh Bovido, on t'as pas sonné !
avatar <<< Kernel Extremist©®™ >>>
Saint Qt, priez pour nous.
Pen^2 - Posté le 12/11/2011 à 14:44 Membre depuis le 10/06/2001, 30231 messages
(bibliothèque c'est plus joli embarrassed)
Zerosquare - Posté le 12/11/2011 à 18:29 Membre depuis le 27/04/2006, 43211 messages
##pointsally##
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo
Nil - Posté le 12/11/2011 à 18:34 Membre depuis le 13/06/2001, 67473 messages
Pen^2 (./15) :
(Tu devrais lui dire quelle est la bibliothèque graphique la plus efficace ; perso je ne suis plus très au courant)
Penpen, t'es quand même un chacal de merde grin
avatar
Folco - Posté le 12/11/2011 à 18:59 Membre depuis le 18/06/2001, 29790 messages
La vache Nil, tu tombes bas, même moi j'avais réussi à ne pas relever. Au prix d'une crise de nerf, ok, mais j'avais tenu bon. #tsss#
avatar <<< Kernel Extremist©®™ >>>
Saint Qt, priez pour nous.
Pen^2 - Posté le 12/11/2011 à 22:41 Membre depuis le 10/06/2001, 30231 messages
Bah quoi, c'est vrai que je ne suis plus très au courant : j'essaie d'informer les nouveaux au mieux, voilà tout #tripo#
Et sinon Lepzulnag, as-tu déjà entendu parler des Kernels ? ##concupiscence##
Folco - Posté le 12/11/2011 à 22:58 Membre depuis le 18/06/2001, 29790 messages
C'est con, t'avais presque retrouvé ta crédibilité avec la première phrase grin
avatar <<< Kernel Extremist©®™ >>>
Saint Qt, priez pour nous.
Pen^2 - Posté le 12/11/2011 à 23:00 Membre depuis le 10/06/2001, 30231 messages
Tu peux faire l'innocent embarrassed
Folco (./12) :
Et pour info, PreOS sauvegarde/restaure 3 lignes sous l'écran pour éviter une partie des désagréments. /v31/gfx/s/smile.gif