Salut à tous,
Mon algorithme en c++ compile bien mais lors de l exécution il me gènére une erreur de segmentation. est ce que quelqu'un a déjà rencontré ce type de message ?
Merci .
Version imprimable
Salut à tous,
Mon algorithme en c++ compile bien mais lors de l exécution il me gènére une erreur de segmentation. est ce que quelqu'un a déjà rencontré ce type de message ?
Merci .
A peu près 100% des développeurs C/C++ l'ont déjà vue, cette erreur, t'inquiète pas... :mouarf:
Tu as dû déréférencer un pointeur non-initialisé, ou taper "trop loin" après une structure ou un container (aller au delà de sa taille). Mais bon, sans le code et la ligne indiquée pour l'erreur, difficile d'être plus précis.
oui clair qu'entre celle là et les autre memory fault , bus error, ...
petite aide pour trouver la cause de l'erreur
http://www.cmi.univ-mrs.fr/~contensi...=env&page=deb5
Salut,
L'erreur de segmentation est sans doute une des erreurs les plus courantes à l'exécution.
Elle survient généralement de manière aléatoire parce que, à un moment, tu essaye d'aller "chipoter" à une adresse mémoire qui n'est plus utilisée dans le contexte où tu essaye d'y accéder.
Le plus souvent, elle est due:
Comme tu peux le remarquer, son origine est très souvent un pointeur ;)
- à un pointeur détruit non remis à zéro,
- à un pointeur NULL non testé,
- à une tentative d'accès au Nieme élément d'une collection qui n'en contient que maximum N-1,
- à une tentative d'accès à un objet pointé par un pointeur qui n'a pas été correctement initialisé (à NULL s'il pointe vers un objet inexistant ou à une valeur correspondant réellement à l'adresse à laquelle se trouve un objet du type adéquat).
Mais, au delà de cela, il faudrait au moins une partie du code pour arriver à en déterminer la cause.
Le plus embêtant de l'histoire, c'est que l'erreur qui finit par provoquer la faute de segmentation est parfois très éloignée du point où elle apparait :P
Merci pour vos réponses, je vais revoir tous les pointeurs de mon code et les containers, et essayer la solution de jabbounet. sinon j envoyerai mon code.
Salut,
bon idee est aussi lancer ton program sous debuger :P
(ou bien ... utiliser "memory checker" comme valgrind etc. mais c'est plus difficile et c'est la solution seulement pour linux).
Fredy
j'ai lancé mon programme avec gdb comme suit :
je ne sais pas j'arrive toujours pas à cerner l erreur? :cry:Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21 anne@anne-desktop:~/Bureau/paradiseo-1.2.1/paradiseo-eo/build/tutorial/FeatureSelection2$ gdb ./FeatureSelectionEA GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"... Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) run Starting program: /home/anne/Bureau/paradiseo-1.2.1/paradiseo-eo/build/tutorial/FeatureSelection2/FeatureSelectionEA Loading model from file ... No such file or directory Program exited with code 01. (gdb) run Starting program: /home/anne/Bureau/paradiseo-1.2.1/paradiseo-eo/build/tutorial/FeatureSelection2/FeatureSelectionEA Loading model from file ... No such file or directory Program exited with code 01.
Fredy Kruger est ce que vous pouvez m'expliquer svp comment je peux utiliser "memory checker parce que je suis sous lunix? Merci
voilà je vous envoie les classes dont je suis sure que l'erreur vient de l'une d'elle.
est ce que quelqu'un peut m'aider?
Salut,
Je n'ai pas tout analysé mais il y au - un truc qui me parait bizarre et qui pourrait expliquer ton problème (ou un futur problème).
Dans eoFeatureSelectionClone.h, dans la fonction void apply(eoPopulator<GenotypeT>&_pop) , tu écris :
Puis ta boucle :Code:_pop.reserve(1000);
Tu fais donc 1100 itérations si je ne m'abuses. Ne serait-ce pas plutôt :Code:
1
2
3
4
5 while (j!=100) { // .... for(unsigned i=0;i<=10;i++) }
Code:
1
2
3
4
5 while (j!=100) { // .... for(unsigned i=0;i<10;i++) }
Salut,
1. Ca c'est quoi ?
Starting program: /home/anne/Bureau/paradiseo-1.2.1/paradiseo-eo/build/tutorial/FeatureSelection2/FeatureSelectionEA
Loading model from file ...
No such file or directory
?????
2. Valgrind
Il faut le telecharger de http://valgrind.org/ et apres lancer "la Sainte Trinité" .... c'est-à-dire
configure ; make ; make install :mouarf:
Moi, je lance valgrind comme ca :
valgrind --leak-check=full --show-reachable=yes --log-file=resultat_in_txt.txt ./binary_a_lancer
Bonne chance. Fredy
( et excusez ma langue francaise )
merci 3DArchi c vrai c'est l'une des erreurs que je mes suis pas rendu compte d eux! en fait c'est un algorithme évolutionnaire qui crée pour chaque individu dix copies, et comme une population comporte 100 individus on va obtenir 1000! et c vrai que ≤ est fausse!
mais ça n empeche le problème d erreur de segmentation persiste encore :(
merci fredy! je vais essayer ce que vous m'aviez proposé!
Pour gdb :
compile avec -g;
essaye insight ou ddd, moins galère à utiliser au début.
Ou alors, fais un mode TRACE :
à chaque début de fonction ou méthode :
et compile avec -D TRACE.Code:
1
2
3
4 #ifdef TRACE std::cout<<"Entré dans fonction"<<std::endl; #endif
Ou enfin, plus dure, regarde du coté de la gestion des execptions...
merci lavock! j'ai essayé toutes ces solutions mais aucune ne marchent pour moi.
pour TRACE j ai fait ce que vous m'avez indiqué mais lorsque je tape make -D TRACE pour compiler cela m 'affiche qu il n y a pas d option de type -D :?
Il n'y a pas d'espace entre D et TRACE : -DTRACE
L'espace est optionel, c'est surtout que tu ne doit pas l'invoquer sur le make mais sur ton compilateur.
Modifie ton Makefile est rajoute ceci à la fin de CXXFLAGS ou de ta ligne de compilation.
Parce que, si je ne m'abuse, la question à été posé par quelqu'un qui ne maîtrise pas encore tout bien. Et le mode trace apporte, pédagogiquement, un intérêt bien plus subtile que le debug (qui de plus s'avère relativement dur à maîtriser pour les débutants).
Mais dans l'ensemble, je suis bien d'accord, une fois GDB maîtriser, le trace est à bannir !
ça apprend a mettre des printf partout dans le code encadré par des directives de compilation....
bref ça peu réduire a lisibilité du code.
pour le débugger pas besoin de le maitriser complètement pour savoir ou ça plante.
Avec un programme compilé et linké avec l'option -g
et une fois dans le debugger tu tappe la commande "bt" pour avoir la pile d'appel et donc la méthode ou ça plante ainsi que la ligne.Code:
1
2
3
4
5 $ulimit -c unlimited $./monprogrammme_qui_plante .... --> genère un fichier core. $gdb monprogrammme_qui_plante <le fichier core genéré précédement>
tu as aussi ses appelant qui sont parfois fautif aussi de fournir des paramètres invalide.
Non, c'est surtout que ça montre de façon rudimentaire et précise comment les appels s'enchaine.
A vrai dire, je ne connaissait pas trop ulimit (vite fait le nom). La question est :
Crois tu vraiment que quelqu'un qui ne maîtrise pas le compilateur (et qui vient surement d'un autre langage style java), arrivera à exploiter le résultat de la commande bt ?
Quoi qu'il en soit, annesophiedecar, pourrais tu, s'il de plait, nous écrire ton Makefile pour qu'on te dise quoi mettre dedans, et ainsi être complet ?
c'est juste pour indiquer que le système peu pondre des fichiers coredump (pour faire des debug post mortem)Citation:
A vrai dire, je ne connaissait pas trop ulimit
je l'ai indiqué au cas ou le compte est configuré par défaut pour ne pas en générer.
Cette commande est parfois utile, car elle peu gérer quelques limites sur les compte utilisateurs (nombre de descripteurs de fichier ouvert simultanément par exemple)
oui je pense.
si l'option -g est positionnée à la compilation, tu as la liste des fonctions qui ont été appelées au moment du plantage ainsi que la ligne dans le fichier source.
il suffit ensuite d'aller dans les fichiers pour regarder.