variables effacées - C - Programmation
Marsh Posté le 08-07-2004 à 14:49:34
bosse avec des pointeurs ou des variables static...
Marsh Posté le 08-07-2004 à 14:53:52
oui, bien sûr. Je l'ai pas mis de suite pour pas décourager lol
la fonction appelée est celle aui s'appelle systdiff. Voici le fichier qui la contient (c'est un petit peu long par contre)
Code :
|
les commandes dvector et free_dvector sont juste utilisées pour allouer et désallouer la mémoire. Elles sont sûres et ont déjà été testées (pas par moi loll).
Marsh Posté le 08-07-2004 à 14:55:59
j'ai essayé de faire aussi clair que possible. les résultats des fonctions gradient et lapl sont alloués à l'intérieur de ces fonctions, donc ca nápparaît pas ici
Marsh Posté le 08-07-2004 à 15:02:15
Code :
|
mmmh, je ne sais pas comment fonctionne ta fonction d'allocation, mais c'est déjà louche ...
ensuite, qu'elle soit fiable ou pas, cette fonction d'allocation, tu n'es pas à l'abris d'un manque de mem ... vérifie que tout a bien été alloué quoi :]
(Edit : étrange ce bug sur les paranthèses dans les sections de code -_-)
Marsh Posté le 08-07-2004 à 15:21:58
been, tu regardes le retour de ta fonction, je suppose que le résultat sera NULL si la mémoire n'a pas pu être allouée
sinon, ... Pour tes tableaux, tu es sur que ce n'est pas plutôt de 0 à n-1 que tu devrais aller ?
Marsh Posté le 08-07-2004 à 15:25:39
non, le pointeur a été bidouillé afin que les indices puissent commencer à une valeur quelconque. par contre, je n'ai jamais de résultat null... tout se passe bien pendant quelques itérations (en tout cas, ca en a l'air), et dún coup, j'ai une variable qui soit n'est plus trouvé, soit prend une valeur (genre 10e304 pour les doubles)
Marsh Posté le 08-07-2004 à 15:29:48
déjà ça c'est dégueulasse :
Code :
|
c'est
Code :
|
Marsh Posté le 08-07-2004 à 15:32:39
les structures non nommées, c'est standard, ca ?
Edit : okok, ca l'est :]
Marsh Posté le 08-07-2004 à 15:39:14
bibi218 a écrit : non, le pointeur a été bidouillé afin que les indices puissent commencer à une valeur quelconque. par contre, je n'ai jamais de résultat null... tout se passe bien pendant quelques itérations (en tout cas, ca en a l'air), et dún coup, j'ai une variable qui soit n'est plus trouvé, soit prend une valeur (genre 10e304 pour les doubles) |
hum ... J'ai quelques doutes sur la manière dont ca a été fait, tu n'aurais pas le source de tes fonctions d'allocation ?
Marsh Posté le 08-07-2004 à 15:44:38
Code :
|
ca c'est pour l'allocation
et pour désallouer ...
Code :
|
Marsh Posté le 08-07-2004 à 16:01:13
d'après les instructions en préprocesseur, la valeur est à 1
Marsh Posté le 08-07-2004 à 16:06:24
bon, quoi qu'il en soit, j'ai de sérieux doutes sur la personne qui a écrit ca (qui caste le retour de malloc )
Utilise des indices plus "classiques", ce sera mieux pour tout le monde.
... ou alors utilise plutôt quelque chose de ce genre, même si je n'ai pas envie de le conseiller tant c'est risqué -_- (cas où le retour pourrait être négatif ....)
Edit en fait, je cache, c'est encore mieux ... Utilise des indices conventionnels, c'est pas la mort d'utiliser i-nl au lieu de i, quand même
Marsh Posté le 09-07-2004 à 10:22:01
J'ai eu un problème similaire, j'avais un indice de tableau (i) que je mettais à jour en fonction du résultat d'une recherche, entre 0 et N-1 si l'element recherché existait dans mon tableau ou -1 sinon et donc quand je voulais incrémenter le nombre d'apparitions de l'element je faisais liste[i].nb++; mais j'avais oublié de vérifier que i était bien supérieur à -1 !
Et en fait dans le cas où i était à -1 ça modifiait une autre variable ce qui foutait le bordel dans mon code ! Je n'avais ce problème que sur la machine de production, sur mon PC ça fonctionnait "bien" !
Marsh Posté le 10-07-2004 à 17:35:41
"nrutil.h" --> tu utilises Numerical Recipes, c'est ça ?
Si oui, je suppose que les fonctions d'alloc et de désalloc de vecteurs sont bonnes. Par contre, il faut se méfier parce qu'il me semble qu'ils utilisent la convention Fortran, à savoir que les indices commencent à 1 et non 0 (d'ailleurs c'est bien ce que tu fais).
Pour la détection d'écrasements mémoire ou de memory leaks, utilise un malloc debugger comme Valgrind si t'es sous Linux.
Sinon mpatrol, ou autre truc du même genre.
Pour le genre d'applis que tu fais, ça ne sera pas inutile.
Marsh Posté le 11-07-2004 à 10:38:39
Y a quoi dans membre_poisson() ? Je veux dire la déclaration et allocation de b ? Si on fait un free_dvector(), il faut espérer que la déclaration interne est conforme/compatible avec le free (on peut pas débobiner qq chose bobiné autrement).
b=membre_poisson(y,n,poisson.h);
....
free_dvector(b,1,n-2);
-------------------------
dy[3*n+i] : dy est suffisament alloué en taille pour pas risquer de déborder ?
-----------------
les for i = sans (, ça fait bizarre
calculE(long unsigned n, faut que j'essaie, long et unsigned doivent être interchangeables. Quand on n'a pas l'habitude de lire dans ce sens..
C'est le code affiché qui, une fois exécuté, provoque la disparition des variables mentionnées ? En inhibant ce traitement, c'est bon ?
Elles sont globales les variables qui disparaissent ? C'est pas le compilo qui les a optimisées (servent plus => pschittt) ?
Marsh Posté le 08-07-2004 à 14:44:07
bonjour à tous, me revoilà encore une fois avec un problème à la noix ...
donc je m'explique : j'ai une fonction de base qui initialise quelques variables, enfin rien de très sorcier jusque là. Jái vérifié, elles sont bien toutes là, avec leur bonne valeur. Ensuite elle appelle une autre fonction, qui fait son bout de chemin tranquille, et une fois celle-ci terminée, plus de trace des mes variables de départ
Cf. GDB pour le message d'erreur
Program received signal SIGSEGV, Segmentation fault.
0x000160ec in odeint (ystart=???, nvar=???, t1=???, t2=???, eps=Cannot access memory at address 0xffffffd8
J'ai pensé à des tableaux, qui auraient pu écraser des variables voisines, mais je ne vois pas à priori où cela se situerait ... quelqu'un aurait-il une idée (autre cause éventuelle par exemple ....) je ne sais plus trop où chercher là