Erreur -1.#INF00 en C
Fermé
Kelm
-
12 mars 2011 à 13:28
fiddy Messages postés 11069 Date d'inscription samedi 5 mai 2007 Statut Contributeur Dernière intervention 23 avril 2022 - 13 mars 2011 à 15:08
fiddy Messages postés 11069 Date d'inscription samedi 5 mai 2007 Statut Contributeur Dernière intervention 23 avril 2022 - 13 mars 2011 à 15:08
3 réponses
Hxyp
Messages postés
401
Date d'inscription
vendredi 28 janvier 2011
Statut
Membre
Dernière intervention
27 avril 2014
54
Modifié par Hxyp le 13/03/2011 à 08:03
Modifié par Hxyp le 13/03/2011 à 08:03
Bonjour,
Je ne sais pas d'où vient le problème j'attendais que quelqu'un donne la réponse ahah , on dirait que i et j sont affectés par la ligne
F[i][j]=((F[i][j-1])-(F[i-1][j-1]))/(X[i-1]-X[i-j]);
Seulement lorsqu'on ajoute une variable sans l'utiliser i et j ne sont pas affectés j'ai testé comme ça :
Sans le "x" et en compilant "normalement" avec
$gcc -c main.c
$gcc -o main main.o
ça créer une boucle infini :
avec le "x" d'ajouté ..
me suis dit que ça venait du code asm généré à la compilation alors en compilant sans la variable x comme ceci avec l'option d'optimisation -O2 :
$gcc -O2 -c main.c
$gcc -o main main.o
pas de boucle infini mais résultat encore différent . . .
Au début je m'étais dit que le problème venait des "i-1" "j-1" et "i-j" mais quand en ajoutant seulement une variable inutile ça change le comportement... j'y comprend rien
Edit: corrections etc
Je ne sais pas d'où vient le problème j'attendais que quelqu'un donne la réponse ahah , on dirait que i et j sont affectés par la ligne
F[i][j]=((F[i][j-1])-(F[i-1][j-1]))/(X[i-1]-X[i-j]);
Seulement lorsqu'on ajoute une variable sans l'utiliser i et j ne sont pas affectés j'ai testé comme ça :
void test(void)
{
double F[2][2]={{1.3,2.4},{4.1,9.3}};
double X[4]={1,2,3,4};
/* le x qui sert à rien ici */
int i,j,n,x;
for(i=1,n=4;i<n;i++)
{
for(j=1;j<=i;j++)
{
printf("i-1 %d j-1 %d i[%d]j[%d]\n",i-1,j-1,i,j);
F[i][j]=(F[i][j-1]-F[i-1][j-1])/(X[i-1]-X[i-j]);
}
}
}
int main(int argc,char **argv)
{
test();
return EXIT_SUCCESS;
}
Sans le "x" et en compilant "normalement" avec
$gcc -c main.c
$gcc -o main main.o
ça créer une boucle infini :
$ ./main i-1 0 j-1 0 i[1]j[1] i-1 1 j-1 -1 i[2]j[0] i-1 1 j-1 -1 i[2]j[0] ...
avec le "x" d'ajouté ..
$ ./main i-1 0 j-1 0 i[1]j[1] i-1 1 j-1 0 i[2]j[1] i-1 1 j-1 1 i[2]j[2]
me suis dit que ça venait du code asm généré à la compilation alors en compilant sans la variable x comme ceci avec l'option d'optimisation -O2 :
$gcc -O2 -c main.c
$gcc -o main main.o
pas de boucle infini mais résultat encore différent . . .
$ ./main i-1 0 j-1 0 i[1]j[1] i-1 1 j-1 0 i[2]j[1] i-1 1 j-1 1 i[2]j[2] i-1 2 j-1 0 i[3]j[1] i-1 2 j-1 1 i[3]j[2] i-1 2 j-1 2 i[3]j[3]
Au début je m'étais dit que le problème venait des "i-1" "j-1" et "i-j" mais quand en ajoutant seulement une variable inutile ça change le comportement... j'y comprend rien
Edit: corrections etc
fiddy
Messages postés
11069
Date d'inscription
samedi 5 mai 2007
Statut
Contributeur
Dernière intervention
23 avril 2022
1 816
Modifié par fiddy le 13/03/2011 à 12:05
Modifié par fiddy le 13/03/2011 à 12:05
Bonjour,
@ Hxyp,
F[i][j]=((F[i][j-1])-(F[i-1][j-1]))/(X[i-1]-X[i-j]);
A la deuxième itération i vaut 2 (condition ok car 2<n).
Le problème est que F[2][j] n'est pas défini car le tableau est de taille [2][2]. Du coup, le programme écrit en dehors du tableau. Selon l'organisation de la pile, il se peut qu'il récrive sur les variables i et autre. Du coup, ça part en boucle infini.
Le fait de rajouter un x fait en sorte qu'il s'intercalera entre la variable i et le tableau F. Du coup en récrivant dans la pile, la réécriture se fera sur x et non sur i. Voilà pourquoi, tu peux avoir des bizarreries comme ça.
Attention donc à bien faire en sorte de ne pas écrire en dehors du tableau. Petite astuce, vous testez la première itération, et la valeur maximale (les limites) et vous regardez si tout se passe bien.
Cdlt,
Google is your friend
@ Hxyp,
F[i][j]=((F[i][j-1])-(F[i-1][j-1]))/(X[i-1]-X[i-j]);
A la deuxième itération i vaut 2 (condition ok car 2<n).
Le problème est que F[2][j] n'est pas défini car le tableau est de taille [2][2]. Du coup, le programme écrit en dehors du tableau. Selon l'organisation de la pile, il se peut qu'il récrive sur les variables i et autre. Du coup, ça part en boucle infini.
Le fait de rajouter un x fait en sorte qu'il s'intercalera entre la variable i et le tableau F. Du coup en récrivant dans la pile, la réécriture se fera sur x et non sur i. Voilà pourquoi, tu peux avoir des bizarreries comme ça.
Attention donc à bien faire en sorte de ne pas écrire en dehors du tableau. Petite astuce, vous testez la première itération, et la valeur maximale (les limites) et vous regardez si tout se passe bien.
Cdlt,
Google is your friend
Hxyp
Messages postés
401
Date d'inscription
vendredi 28 janvier 2011
Statut
Membre
Dernière intervention
27 avril 2014
54
Modifié par Hxyp le 13/03/2011 à 14:32
Modifié par Hxyp le 13/03/2011 à 14:32
Merci fiddy, je comprend mieux maintenant ! Par contre encore un problème testé avec un simple tableau et j'ai bien une "erreur de segmentation" quand je le dépasse de lui même par exemple char a[2]; a[2]='x'; ,mais pas d'erreur quand je passe d'un tableau à un autre et que je dépasse l'autre avec le premier
résultat : hexlo
normalement devrait pas y avoir une erreur ?
Aah j'ai compris là, l'erreur survient que lorsque la mémoire totale est dépassée du coup il est permit d'écraser d'autre variables tant qu'il y a de la place! avec le code ici ça donne 6char+2char+1int = 8+4 = 12 oct max
du coup on peut faire x[11]='x' sans erreur mais x[12]='x' y a l'erreur !!! eureka ahahah
Merci encore !
#include <stdio.h>
int main()
{
char a[6]="hello\0";
char x[2];
int i; for(i=0;i<6;i++)
{
x[i]=a[i];
}
x[2]='x';
printf("%s\n",x);
return 0;
}
résultat : hexlo
normalement devrait pas y avoir une erreur ?
Aah j'ai compris là, l'erreur survient que lorsque la mémoire totale est dépassée du coup il est permit d'écraser d'autre variables tant qu'il y a de la place! avec le code ici ça donne 6char+2char+1int = 8+4 = 12 oct max
du coup on peut faire x[11]='x' sans erreur mais x[12]='x' y a l'erreur !!! eureka ahahah
Merci encore !
fiddy
Messages postés
11069
Date d'inscription
samedi 5 mai 2007
Statut
Contributeur
Dernière intervention
23 avril 2022
1 816
13 mars 2011 à 15:08
13 mars 2011 à 15:08
Eh voui, plus on déborde dans la pile, et plus on risque d'écraser des bytes importants. Par exemple, tu peux écraser l'eip au sein d'une fonction (principe souvent utilisé pour l'exploitation des stack overflow). En récrivant à des endroits interdits, tu obtiendras un segfault.
Bonjour ,
Tout d'abord ,merci pour vos réponse .
J'ai passé quelque minutes à chercher une solution après avoir lu vos réponse . J'ai fait des printf partout et j'ai trouvé !
Un truc Bête et débile ... Je divisais pas 0 c'est pour ça qu'il me faisait forme indéterminée.
Désole de vous avoir fait perdre votre temps .
Tout d'abord ,merci pour vos réponse .
J'ai passé quelque minutes à chercher une solution après avoir lu vos réponse . J'ai fait des printf partout et j'ai trouvé !
Un truc Bête et débile ... Je divisais pas 0 c'est pour ça qu'il me faisait forme indéterminée.
Désole de vous avoir fait perdre votre temps .