Il est possible que ton programme ait écrit par-dessus les instructions (débordement de tableau par ex), ce qui donne n'importe quoi.
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas
. »
Compare les octets après compilation et après execution. Si y a une différence c'est que c'est un débordement comme vient de le signaler sasume. Sinon peut être un bug du débuggueur VTI...?
PpHd Le 19/01/2005 à 12:20 >j'ai vu que PpHd avait noté pour les fonctions 000a 000b, 000c "I use this, because, else a strange bug appears". Il s'agit de la même chose?
Je ne pense pas.
Le code "transformé" est celui de genlib ?
Quelle version ?
Avant même d'exécuter ton programme, quel est le code des fonctions @000a et @000b ?
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas
. »
PpHd Le 19/01/2005 à 13:16 Charge ton programme (Met un BP a _main). Et va voir directement ton code de mul ce qu'il est.
PpHd Le 19/01/2005 à 13:16 Si c'est le code que tu avais tape dans ton editeur de texte favori, tu mets un set data BP (Write) dessus et tu continues l'execution.
PpHd Le 19/01/2005 à 13:35 Tu peux pas extraire ce bug dans un testcase reduit ?
peut-être que mulu.l n'existe pas ?
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)
<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant
PpHd Le 20/01/2005 à 14:06 SI les adresses du code ne sont pas en RAM, c'est AMS.
PpHd Le 20/01/2005 à 15:37 Mon probleme est que je n'ai plus touche a la prog ti depuis 1 mois (Boulot de 8h a 20h, ca epuise).
