Plantage "aléatoire dans le temps" ! - Page 1

J'aimerais juste savoir d'où peut provenir un plantage "aléatoire dans le temps" dans un programme.

Je m'explique : je ne rencontre aucun problème durant l'exécution du programme mais parfois, en plein milieu (pas réussi à trouvé quand exactement^^) le programme se bloque et on ne peut plus rien faire (comme une boucle infinie), aucun message d'erreur et les niveau de gris sont toujours la ! Le problème est que ca peut arriver au bout de quelques secondes, mais des fois après 30 minutes, il n'a toujours pas planté !

Alors quel type de bug est-ce ?

Je suppose un dépassement de mémoire, mais je vois pas où...
Est-ce qu'il peut y avoir un autre type de bug ?

ça peut venir d'une variable non initialisée (je parle d'expérience).

ça peut venir de pas mal de choses, mais c'est très souvent un problème de dépassement de mémoire en effet :/

Oui, en général un dépassement de tampon...
Avec quel niveau de warnings compiles-tu ? En-dessous de -Wall -W, c'est pas bien

(et accesoirement c'est assez normal que les NVG soit tjrs actifs)

Ben ça dépend de la nature du plantage...

Je compile bien en -Wall -W. (options de base de tigcc)

J'ai juste une question : si on ajoute 1, à un unsigned int initialisé à 0, en permanence, arrivé à 65535 la valeur d'après est 0 ?
Ou ca peut provoquer une erreur ?

la valeur d'après est 0, c'est garanti ^^ (par contre pour les int signés c'est différent, en principe t'as pas le droit d'ajouter 1 à 32767 -- mais en pratique sur TI les compilateurs font comme si t'avais le droit de le faire)

Tu veux dire que dans d'autres environnements des tests sont mis en place pour éviter ce problème ?

Sasume :
Ben ça dépend de la nature du plantage...

Dans 90% des cas le plantage est un "Address Error" (ou assimilé) donc ne touchant pas aux ints, donc les nvg sont tjrs présents vu que l'int des nvg est tjrs active

Sasume :
Tu veux dire que dans d'autres environnements des tests sont mis en place pour éviter ce problème ?

certains processeurs ont effectivement une addition signée qui lance une exception en cas d'overflow pour que tu puisses savoir qd il y a overflow, mais en fait c'est plus souvent le contraire : le processeur n'a que des additions normales donc tu ne sais pas s'il y a overflow ou pas, mais le compilo suppose, lui, qu'il n'y a jamais d'overflow et peut donc faire des simplifications (du coup il peut simplifier a-1>=42 en a>=43, ce qui ne serait pas possible avec a unsigned) ((enfin c'est tout à fait possible que tigcc aussi ait ce genre d'optimisations qui font que ça casse subtilement :/ mais bon, tellement de programmes TI font des overflow signés que en pratique, pour les cas simples, ça marche même si c'est Mal))

Pour ça il faut que le CPU ai des opération sur des nombres signé

Pour mon problème c'est surement un problème de dépassement de mémoire puisque j'ai des problèmes à l'affichage (pixels mauvais) !
Reste plus qu'a trouver où!!!

un peu hs: ya moyen d'avoir des warnings quand on initialise pas tous les champs d'une structure ?

#14: je pense que non, ça me parais difficile..

#12: ha oui ça m'avais échapé dans le post

Un certain nombre de warnings "fines" ne sont pas dans -W -Wall... mais si le code est fait d'une certaine façon, l'activation de certaines warnings donne un flot monstrueux de warnings...

et avec -pedantic ? (après avoir purgé les warnings qui viennetn des .h)

Le -pedantic n'est pas supporté par TIGCC ^^

J'ai résolu mon problème
C'était bien un dépassement de mémoire, mais pas facile à voir^^. Juste deux indices inversés

Merci pour vos réponses

Ça a dû être bien chiant à trouver

Oui ^^
En fait ce bug est présent depuis la version 0.6, soit avril 2004 !
J'ai mis plus de 2 ans à m'en rendre compte et à le trouver^^

C'était dans grav ?

D'ailleurs je vais mettre la nouvelle version en ligne dans pas longtemps

Je suis peut-être rouillé, mais pour ma culture personnelle, TIGCC peut donne des warning lorsqu'il y a possibilité de 'buffer underrun' ?

Je demande ça parce que je vois mal comment il peut le détecter à la compilation.

heu pas à ma connaissance non (si ça existait, ça ne marcherait que dans très peu de cas, donc pas interessant)

Zephyr :
heu pas à ma connaissance non (si ça existait, ça ne marcherait que dans très peu de cas, donc pas interessant)

C'est ce que je me doutais. J'excluait effectivement les cas triviaux du genre:

int a[5];

a[6] = 6;

Mais je ne me rapelle pas non plus si ces cas triviaux peuvent être 'warnés'.

non et théoriquement il ne peut meme pas dans de tel cas, sauf si ton code est uniquement :


void main()
{
int a[5];
a[6] = 6;
}

C'est bien les limitations que j'avais en tête.