Discussion :

[nina2007]

Bonjour à tous

voici mon probleme:

qd j'execute mon prog (gourmand en espace memoire), j'obtiens le message suivant
" Erreur de segmentation (core dumped)"

est ce qu'il s'agit nécessairement d'un pb de mémoire ou ça peut constituer un pb de programmation (allocation de pointeur par exemple)?
comment pourrai-je savoir s'il s'agit d'un pb de memoire, sachant que j'en doute fort (je possede une RAM de 2 Giga)???
merci de m'aider

[d'Oursse]

en general, ca vient du fait que tu lis ou ecris dans une zone memoire non allouee (style un pointeur non alloue que tu dereferences, ou un tableau a n elements et tu tentes d'acceder a l'element n+1 par exemple)

Pour trouver ou se trouve l'erreur :
1) compiler ton prog avec l'option -g (avec gcc)
2) utiliser gdb ainsi:

gdb mon_prog

un prompt apparait :

>

execute la commande run:

> run

le programme s'execute et s'arrete au moment su seg fault. Execute la commande bt:

> bt

et tu verras la succession d'instructions qui aboutissent au seg fault, avec le fichier et la ligne fautive (ligne que tu n'aurais pas eue si tu avais compile sans -g)

Remarque : valgrind est aussi un outil a utiliser. Il (ou plutot son module de check de memoire) ne permet pas a proprement parler de detecter les seg fault, mais il te dit si tu lis ou scris dans des zones non autorisee et qui ne se terminent pas en seg fault. Tres utile pour trouver des bugs vicieux dans ton prog). C'est un tres bon outil. A la abse il sert pour trouver les fuites de memoire. Il y a d'autres outils tres interesants pour faire de la prog efficace.

[nina2007]

qd je tape la commande gdb comme suit;

gdb ./test res.bin out.txt PT2.bin descPrimary.txt F1.txt F2.txt F3.txt

voila ce que j'obtiens

Excess command line arguments ignored. (out.txt ...)
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".
"/home/lbo/GBAR_MVC1/res.bin" is not a core dump: File format not recognized
(gdb)


je ne comprends pas ce qui se passe??????

[nina2007]

qd j'execute le run il m'affiche erreur en nombre d'argument alors que le nb d'arguments est correct ensuite avec le bt resultat "program exit normally"
que signifie le No Stack???



(gdb) run
Starting program: /home/lbo/GBAR_MVC1/test

Erreur en nombre d'argument

Program exited normally.
(gdb) bt
No stack.
(gdb)

[nina2007]

merci pour le conseil...
mais c pas évident de revoir du code qu'on a écrit depuis 1 an de plus que c un peu complexe mais est ce que g vraiment le choix

[nina2007]

ce que je ne comprends pas c le resultat du debogueur (voir mon post précédent)

pourquoi ce message "Program exited normally"????

[frp31]

ton programme dois de toute facon tester systématiquement la mémoire a allouer avant de le faire chaque fois que tu ne le fais pas tu te mets à la faute.

quand a avoir 2Go de mémoire et donc se croire protéger : rien a voir ! c'est pas la taille qui compte mais la facon dont on s'en sert.
un bon programme doit tourner de manière égale sur une machine de 256Mo ou de 16Go de ram c'est juste la vitesse d'exécution et la taille du bloc de donnée chargé à la fois qui compte à condition d'avoir bien sur respecter la condition pré citée.

pour en revenir à ton erreur réelle avoir 2go c'est pas ce qui compte ce qui compte c'est de savoir ce qui est libre et de ne pas charger un bloc de donnée plus grand que l'espace mémoire libre à l'instant T.

l'erreur classique est de se dire mon programme fait 1Mega et le fichier traiter 1go il faut 1,001 Go pour le faire tourner en réalité il faut 1 mega + 1giga +X variables total par exemple 260 megas + Y blocs de données total par exemple 512Mo soit plus d'1.5Go loin des 1 go prévu dans cet exemple c'est pourquoi il faut tjrs faire des malloc et realloc même 100 fois par programmes et tjrs dans un if !!!!! pour voir si c'est possible ou pas afin que le programme ne puisse jamais planter sans rendre la main (ni faire de core dump) mais tjrs sortir avec un statuts d'erreur en nettoyant du mieux possible ces actions tant dans la mémoire que dans d'éventuels fichiers traités...

C'est facile à dire je sais mais on me l'a assez reproché pour que je retienne la leçon...
alors je donne le conseil à mon tour.