erreur mémoire lors de l’exécution d'application console C++

Version imprimable

28/02/2012, 18h28
soufianee

erreur mémoire lors de l’exécution d'application console C++

bonjour tous le monde, pendant l’exécution de mon application console avec C++ avec le compilateur cygwin sous netbenas 6.9.1 cet erreur est s'affiche toujoure en fin :

cygdrive/C/program files/netbeans 6.9.1/ide/bin/nativeexecution/dorun.sh: line 33: 5508 aborted <core dumped> sh "{SHFILE}"

je fait des teste pour trouver la source d'erreur et je constate que la construction d'un objet qui génère l'erreure mais je ne trouve pas des soucis dans le constructeur.
SVP si il y'a des idée pour régler ce soucis je vous appréciez beaucoup
28/02/2012, 22h48
3DArchi

Citation:

Envoyé par soufianee

je fait des teste pour trouver la source d'erreur et je constate que la construction d'un objet qui génère l'erreure mais je ne trouve pas des soucis dans le constructeur.

S'il n'y a pas de soucis, il y a peut être des bugs ?
Blague à part, en l'absence de code il est difficile de répondre à ta question. Un <core dumped> ça peut être énormément de chose
28/02/2012, 23h20
jabbounet

Citation:

Envoyé par 3DArchi

S'il n'y a pas de soucis, il y a peut être des bugs ?
Blague à part, en l'absence de code il est difficile de répondre à ta question. Un <code dumped> ça peut être énormément de chose

pas <code dumped> mais <core dumped> c'est la façon dont les programmes te génère des infos pour le debug post mortem pour les applications sous linux, et cygwin aussi.

je te conseille de rechercher un fichier core, si le 5508 représente le numéro de PID de ton processus il est possible que le fichier se nomme core.5508

Quand tu trouve ce fichier je te conseille de regarder comment lancer un debug postmortem avec gdb en supposant que le compilateur utilisé est gcc ou g++ (fort probable avec cygwin).

L'autre solution si tu ne trouve pas le fichier core ou qu'il manque les info de debugage est de recompiler ton application avec l'option -g.
Ensuite de lancer le programme avec le debugger (gdb ici) et d'attendre qu'il stoppe quand il détecte un problème (à priori un signal 6 vu que c'est un abort) la tu trouvera sur quelle ligne il plante et tu pourra inspecter les variable, voir la pile d'appel, les thread et ce qu'ils font ....
29/02/2012, 07h19
3DArchi

Citation:

Envoyé par jabbounet

pas <code dumped> mais <core dumped>

Petite dyslexie corrigée.

Ceci dit, je pense que debugger son programme ira plus vite, non ?
01/03/2012, 00h45
jabbounet

Citation:

Envoyé par 3DArchi

Petite dyslexie corrigée.

Ceci dit, je pense que debugger son programme ira plus vite, non ?

tout dépend de la complexité du programme et de la reproductibilité du plantage.
Si le bug se produit rarement ou que les condition d'apparition sont complexe le post-mortem peu être plus efficace.

Après il faut aussi regarder si le plantage n'est pas du à une fuite mémoire a force de demander des ressources au système il finit par dire non....
un petit coup de valgrind (si présent sous cygwin ne fait jamais de mal)