la fonction fclose() provoquant faute de segmentation
J'ai un fichier texte délimité par tabulation que je suis de l'analyse. Sa première colonne contient des chaînes de format chrX
, où X
désigne un ensemble de chaînes de caractères, par exemple, "1", "2", ..., "X", "Y".
Ils sont tous stockés dans un char*
appelé chromosome
, comme le fichier est analysé.
Le fichier texte est trié sur la première colonne de manière lexicographique, c'est à dire, je vais avoir un certain nombre de lignes commençant par "chr1", et puis "chr2", etc.
À chaque "chrX entrée", - je besoin pour ouvrir un fichier qui est associé à cette entrée:
FILE *merbaseIn;
//loop through rows...
if (chromosome == NULL)
openSourceFile(&chromosome, fieldArray[i], &merbaseIn, GENPATHIN);
else {
if (strcmp(chromosome, fieldArray[i]) != 0) { //new chromosome
fclose(merbaseIn); //close old chromosome FILE ptr
free(chromosome); //free old chromosome ptr
openSourceFile(&chromosome, fieldArray[i], &merbaseIn, GENPATHIN); //set up new chromosome FILE ptr
}
}
//parse row
J'ai la fonction openSourceFile
est définie comme suit:
void openSourceFile (char** chrome, const char* field, FILE** filePtr, const char *path) {
char filename[100];
*chrome = (char *) malloc ((size_t) strlen(field));
if (*chrome == NULL) {
fprintf(stderr, "ERROR: Cannot allocate memory for chromosome name!");
exit(EXIT_FAILURE);
}
strcpy(*chrome, field);
sprintf(filename,"%s%s.fa", path, field);
*filePtr = fopen(filename, "r");
if (*filePtr == NULL) {
fprintf(stderr, "ERROR: Could not open fasta source file %s\n", filename);
exit(EXIT_FAILURE);
}
}
Le problème, c'est que mon application se ferme avec une erreur de Segmentation passant de la première chromosome de la seconde (à partir de chr1
à chr2
) à la ligne suivante, où j'ai fermer le premier chromosome fichier que j'ai ouvert:
fclose(merbaseIn);
Je sais que je ne suis pas de passage fclose
un pointeur NULL, parce que, jusqu'à la Faute de Segmentation, je suis de la lecture des données à partir de ce fichier. Je peux même conclure à une condition, et je reçois toujours la Faute:
if (merbaseIn != NULL) {
fclose(merbaseIn);
}
De plus, je sais openSourceFile
de travaux (au moins pour chr1
, lors de la mise en place du premier descripteur de fichier de FILE*
) parce que mon application analyse chr1
lignes et lit les données à partir de la FILE*
fichier source correctement.
Qu'est-ce fclose
appel qui est à l'origine une erreur de Segmentation à se produire?
OriginalL'auteur Alex Reynolds | 2009-09-18
Vous devez vous connecter pour publier un commentaire.
Il est très probable que l'erreur est causée par la corruption de la mémoire sur le tas, pas quelque chose qui touche les habitants. Valgrind va immédiatement vous montrer la première erreur d'accès que vous faites.
Edit: Le
--db-attach
option pourvalgrind
a été déprécié depuis la version 3.10.0 en 2014. Les notes de publication de l'état:http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver
free
sur les pointeurs à l'intérieur de la double pointeur. J'ai aussi été pas libérer les pointeurs ailleurs. J'ai scrappé cette application et il a écrit à partir de zéro, l'exécution devalgrind
que je suis allé le long d'à s'assurer que j'étais gestion de la mémoire correctement. Merci de m'indiquer cet outil!Ouais, valgrind m'a appris: 1) comment tout le monde avait raison, et je n'ai utilisé smart (auto/refcount etc.) pointeurs ou de la collecte des ordures et 2) avec valgrind je n'ai pas vraiment besoin de collecte des ordures. Le seul inconvénient est de la couverture de test. Je pense qu'il est plus facile de trouver des fuites de mémoire w/ valgrind qu'avec n'importe quel outil pour GC langues (par exemple, la JVM ou .NET languages) que je suis familier avec.
OriginalL'auteur Jonathan Graehl
une erreur que je remarque c'est cette ligne:
qui devrait être:
C'est parce qu'une chaîne a une fermeture à 0 à la fin vous avez également pour faire de la place pour
Dans ce cas, vous pouvez utiliser strdup() pour remplacer la fonction malloc()+la fonction strcpy().
Je suis en désaccord avec l' (char *) en fonte qui stipule clairement l'intention.
Merci de m'indiquer cette erreur.
OriginalL'auteur Toad
Meilleure supposition est qu'une autre partie de votre code corruption de la mémoire au travers d'un dépassement de tampon ou de bug similaire.
Bien que peu probable pour être la cause, vous avez un potentiel de dépassement de la condition de nom de fichier dans votre tableau lorsque le nom complet du fichier est supérieure à 100 caractères.
Je vous suggérons d'utiliser un débogueur à l'affût des changements dans l'emplacement de mémoire utilisé par le merbaseIn variable.
OriginalL'auteur Paul Dixon
Pointeur Générique Problème
C est une grande langue, mais il exige que vous pas pour tabasser votre propre mémoire. Outre le problème précédemment noté des cas où la fonction malloc est de 1 octet à court, vous pouvez avoir d'autres problèmes avec le pointeur.
Je dirais à l'aide d'un débogueur mémoire. Dans le passé, Clôture Électrique était plutôt populaire, mais ces jours, je entendre plus au sujet de valgrind. Il ya beaucoup d'autres choix.
OriginalL'auteur DigitalRoss
En plus erreur trouvée par reinier, je soupçonne que:
devrait être suivie par:
afin de prévenir les risques de l'utilisation de l'un n'est plus valide.
OriginalL'auteur mouviciel
pourquoi ce FICHIER** filePtr si seulement ce FICHIER* filePtr serait suffisant ?
juste une pensée...
NULL
après la fermeture, car il n'est pas l'argument de fonction.OriginalL'auteur Mandrake
valgrind
avecmemcheck
est certainement le bon outil pour découvrir la cause de l'erreur de segmentation. Utiliser un débogueur avecvalgrind
, notez que le--db-attach
option pourvalgrind
a été abandonné depuis Valgrind 3.10.0 a été publié en 2014. Les notes de publication de l'état:http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver
OriginalL'auteur Dan Yard
Examen de chaque endroit où vous avez utilisé "malloc" et de voir si vous avez fait une erreur.
Par exemple, j'ai été mettre des lignes lues à partir d'un fichier dans un char**, mais j'ai tort
malloced comme:
Quand il aurait dû être:
OriginalL'auteur J.M.I. MADISON