pb de memoire de programmation???

nina2007 · Le 11/08/2007, à 11:25

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

tshirtman · Le 11/08/2007, à 14:21

c'est surement un problème de programmation, (sinon ton programme bloquerais,si il bouffait tes 2G de ram + ta swap, et tout le systeme aurais du mal).

tu a vérifié toutes tes allocations/libérations de mémoire? (genre tu tente de libérer la racine d'une chaine ou alors l'adresse du pointeur et non le pointeur)

enfin amuse toi bien c'est les grandes joies du C

Dernière modification par tshirtman (Le 11/08/2007, à 14:22)

trucutu · Le 11/08/2007, à 17:55

Pour débugguer, tu peux compiler avec l'option -g puis utiliser gdb. Ou sinon, avec des printf....

Marabout · Le 11/08/2007, à 18:04

Salut,

Peut-être que si tu postais ton code on pourrait t'aider.

AuraHxC · Le 11/08/2007, à 18:20

Pour ce genre de problème je conseil "valgrind"
Pour les erreurs de segmentation c'est assez radical

nina2007 · Le 11/08/2007, à 19:32

j'ai fait le debogage et voici le resultat:

Program received signal SIGSEGV, Segmentation fault.
0xb7d94596 in malloc () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0 0xb7d94596 in malloc () from /lib/tls/i686/cmov/libc.so.6
#1 0xb7f56207 in operator new () from /usr/lib/libstdc++.so.6
#2 0x08054a52 in tree_GMF::construire_regles (this=0xbfcb1494, e=0x80ce9b0,
i=2) at tree_GMF.cpp:1052
#3 0x080552cd in tree_GMF::construire_regles (this=0xbfcb1494, e=0x0, i=2)
at tree_GMF.cpp:1248
#4 0x08055416 in tree_GMF::construire_regles (this=0xbfcb1494, e=0x0, i=2)
at tree_GMF.cpp:1275
#5 0x08055267 in tree_GMF::construire_regles (this=0xbfcb1494, e=0x81eaca0,
i=2) at tree_GMF.cpp:1236
#6 0x08055416 in tree_GMF::construire_regles (this=0xbfcb1494, e=0x0, i=2)
at tree_GMF.cpp:1275
#7 0x08055267 in tree_GMF::construire_regles (this=0xbfcb1494, e=0x81eab50,
i=2) at tree_GMF.cpp:1236
#8 0x08055267 in tree_GMF::construire_regles (this=0xbfcb1494, e=0x80ce670,
i=2) at tree_GMF.cpp:1236
#9 0x08055416 in tree_GMF::construire_regles (this=0xbfcb1494, e=0x0, i=2)
at tree_GMF.cpp:1275
#10 0x080552cd in tree_GMF::construire_regles (this=0xbfcb1494, e=0x0, i=2)
at tree_GMF.cpp:1248
#11 0x08055416 in tree_GMF::construire_regles (this=0xbfcb1494, e=0x0, i=2)
at tree_GMF.cpp:1275
#12 0x08055267 in tree_GMF::construire_regles (this=0xbfcb1494, e=0x81eaa00,
---Type <return> to continue, or q <return> to quit---

lunique · Le 12/08/2007, à 13:35

Est ce que tu n'aurai pas une boucle infinie cachée dans l'appel à la construction de ton arbre ?

nina2007 · Le 13/08/2007, à 01:20

Non au fait c'est une fonction récursive

Compte anonymisé · Le 13/08/2007, à 08:14

Salut

Une erreur classique en c est de définir un tableau par exemple :
int tableau[12];
puis d'essayer d'implémenter la valeur :
tableau[12] = 5;
car les valeurs d'indice commencent à 0. Dans le cas précis :
tableau[0] à tableau[11] sont valides.

Je ne sais pas si c'est le cas mais vérifie de ce coté là.

@+

littleblackdog · Le 13/08/2007, à 10:10

un segmentation fault, c'est typiquement dû au fait que, quelque part dans la course de ton programme, tu lui dis d'écrire à un endroit non prévu.

en particulier, comme le dit jeanjd, le fait de vouloir affecter une valeur en dehors des bornes d'un tableau, ou tout simplement le fait d'avoir incorrectement déclaré le tableau en question (avec un malloc, par exemple). si y a rien au bout de ton pointeur, ça arrive aussi.

une méthode pour regler ce genre de problème : insère des affichage de debug du genre : printf("<numéro de la ligne>\n"); qui serviront de jalons lors de l'exécution de ton code. ça te servira à localiser la cause de ton erreur de segmentation, et donc à pouvoir la regler.
pour les codes importants, le mieux est de trianguler, en localisant le segfault de façon de plus en plus précise.

bonne chance, tu y arriveras j'en suis sûr.

tshirtman · Le 13/08/2007, à 10:13

c'est pendant la construction de l'arbre? tu devrait tenter des petits printf, qui te permetraient de savoir si tu est en train de monter une branche, si tu est arrivé un bout, ou si tu redescend enfin le résultat de tes "if" car vu que ça se passe pas a la première opération, ça dépends surement de ça.

@jeanjd63, non c'est pas un tableau c'est un arbre (légerement plus évolué, et utilisation un peu différente) l'erreur classique de l'abre étant de libérer la racine (qui est un pointeur et non un élément de l'arbre).

nina2007 · Le 13/08/2007, à 19:28

voila le debogueur m'indique maintenant, une segmentation fault non plus ds un malloc mais in IO_filexspuntn()

qu'est ce que ça signifie?

Program received signal SIGSEGV, Segmentation fault.
0xb7d78191 in _IO_file_xsputn () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0 0xb7d78191 in _IO_file_xsputn () from /lib/tls/i686/cmov/libc.so.6
#1 0xb7d6eccf in fwrite () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7f0f196 in ?? () from /usr/lib/libstdc++.so.6
#3 0xb7f0ad75 in std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::_M_insert_int<long> ()
from /usr/lib/libstdc++.so.6
#4 0xb7f0aff0 in std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::do_put ()
from /usr/lib/libstdc++.so.6
#5 0xb7f1387d in std::ostream::operator<< () from /usr/lib/libstdc++.so.6
#6 0x08054b1d in tree_GMF::construire_regles ()
#7 0x08055320 in tree_GMF::construire_regles ()

tshirtman · Le 13/08/2007, à 20:44

le fait que l'erreur soit produite par une fonction de la libc ne veut pas dire que l'erreur est là, mais plutot dans la dernière fonction dont tu est l'auteur, il faut donc remonter a cette fonction appelante:

#6 0x08054b1d in tree_GMF::construire_regles ()

et c'est l'appel a la fontion "<<" (pour un cout?) qui produit l'erreur...

#5 0xb7f1387d in std::ostream::operator<< () from /usr/lib/libstdc++.so.6

a toi

nina2007 · Le 13/08/2007, à 21:05

stp tshirtman, je n'ai pas tres bien compris
tu veux dire que l'erreur ce qui est affiché par
#5 0xb7f1387d in std::ostream::operator<< () from /usr/lib/libstdc++.so.6

et donc par la fonction cout?

tshirtman · Le 13/08/2007, à 21:34

l'erreur est levé quand il transforme (avec l'opérateur "<<") ce que tu veut afficher pour l'afficher, la variable que tu veut lui faire afficher ne doit pas exister (le pointeur pointe sur un emplacement non valide). C'est donc sur la ligne de ton cout oui.

teckel_malin · Le 14/08/2007, à 11:17

Bonjour,

je me permets de faire une remarque.

je programme en fortran (cacluls scientifiques).
j'ai aussi 2Go de ram et 4 Go de swap (qui ne sert jamais à rien...)

lorsque j'ai l'erreur
"segmentation fault (core dumped)"

ça provient effectivement d'un probleme de memoire (pour moi en tout cas).
pour les autres erreurs d'allocation et autres l'erreur porte un numéro en général.

fait un test avec un programme ou tu alloues des matrices vraiment énormes volontairement.
ton programme pourra tourner si tes matrices sont petites et si tu augmentes la taille progressivment au bout d'un moment, et bah ça marche plus.

en fait les compilos (pour fortran en tout cas) n'autorisent le programme qu'à utiliser un espace restreint de mémoire (256Mo je crois). pour laisser au systeme de quoi respirer. ensuite on peut rajouter des tranches ("segments") de 256Mo supplémentaires. etc...

pour faire sauter cette limite, tu tapes dans le terminal (en bash) avant de lancer ton prog.

 machin@machin:~$ ulimit -s unlimited

la tu autorises le systèmes un nombre illimité de tranches (dans la limite des stocks disponibles)
et ça devrait regler le probleme (moi je fais comme ça quand je traite plein de données).
c'est valable dans le terminal tant que tu l'as pas fermé.

il y a des options de compilation suivant les compilateurs genre -bmaxdata etc... c'est plus fin mais je maitrise pas.

NOTE : en csh c'est plus du genre "ulimit size unlimited"

si ça peut t'aider....

Gassoumi Taoufik · Le 17/08/2007, à 11:56

Marabout a écrit :

Salut,
Peut-être que si tu postais ton code on pourrait t'aider.

Je suis un pauvre étudiant car je n'ai pas encore trouvé ce qui vraiment peut m'aider !!!

J'ai beaucoup de la chance dans ma vie..mais parfois j'ai des ruptures bizar!!!!!!!

s'il vous plait j'ai un code mais j'ai essayé 1000 fois (depuis 6 mois) de l'exécuter mais pas encore..
malgré que j'ai un exemple de données et de résultats numériques.... donc pour les mêmes data il faut q'on aura les mêmes résultast!
je l'ai trouvé sur un livre copie poor quality(s'exécute avec mictrosoft fortran 4: je ne possède pas ce software) et je veux l'exécuter avec f77 puis je vais rajouter mes besoins par la suite.....
mais tjs au premier pas, si quelqu'un peut m'aider je vais envoyer une copie par email....

votre email please...

SOS SOS SOS SOS

AuraHxC · Le 17/08/2007, à 12:06

Les seg fault en C ont très souvent rien a voir avec la taille de ta mémoire mais plutôt a l'allocation dynamique ou tu essaie d'avoir accès a une partie de la mémoire ou tu n'as pas le droit ou une mauvaise utilisation de celle ci (mais très très rarement, voir jamais surtout dans les petits programmes, un soucis de taille de ta mémoire).

Et si tu fais un valgrind sur ton programme (regarde comment ca s'utilise) et que tu nous donne la source peut être que l'on pourra résoudre le problème plus efficacement.

Toug · Le 17/08/2007, à 12:15

[youtube]http://www.youtube.com/watch?v=[/youtube]

SOS
j'ai trouvé un programme dans un ancien livre poor quality
avec des exemples de données et de résultats..qui est déjà éxécuté avec MSFortran 4
je n'ai le microsoft fortran 4, donc je le copie (4000 lignes) et j'ai essayé de l'éxécuter avec f77 mais tjs il y des problèmes.. depuis 6 mois....

j'ai beaucoup besoin de ce programme car je vais rajouter mes besoins.....et validation..
please help me!!!! si vous pouvez m'aider donnez-moi votre email et je vais vous envoyer 1 copie!!!!!!

AuraHxC · Le 17/08/2007, à 12:31

Je viens rien dans ta balise code et n'on plus rien avec ton truc flash...
Avant de copier/coller est ce que tu as lu le code et surtout est ce que tu le comprend, parce que dans les bouquin parfois il y a des erreurs donc il faut au maximum lire et comprendre le code pour en profiter.

tshirtman · Le 17/08/2007, à 13:44

Alors au lieu d'executer un code que tu ne comprends pas ilvaudrait mieux que prenne le langage par les bases, que ce soit le c ou le fortran que tu veux utiliser il y as quantité de cours bien expliqués et a jours pour apprendre (en c surtout, peut être u peu moins en fortran).

Pour les cours de c en français il y as sur commentcamarche.com et lesiteduzero de manière générale il y as aussi wikipedia comme point de départ!

bon courage!

si tu n'as pas les compétences pour produire le code dont tu as besoin, il vaudrait mieux trouver un arrangement (financier souvent) avec quelqu'un capable de le produire, car pour ce qui est de "valider" un code que tu ne comprends pas, je ne vois pas comment tu compte faire. recopier 4000 lignes a la mains sans les comprendres est aussi un bon moyen d'avoir un truc qui ne marche pas sans avoir lamoindre idée de pourquoi ni la moindre chance de trouver (a moins de relire en parralèles les 4000 lignes des deux cotés, 8000 lignes quoi,et ne pas encore être sur...)

Dernière modification par tshirtman (Le 17/08/2007, à 13:48)

AuraHxC · Le 17/08/2007, à 13:56

@tshirtman : +1 c'est exactement ce que je disais. Si tu comprends pas ce que tu copie/colle c'est pas vraiment intéressant et après en cas de soucis ben pas moyen de s'en sortir.

Toug · Le 17/08/2007, à 19:46

Salut je vous remercie bien pour votre attention et conseils.

voilà j'ai ce programme :

program test

implicit double precision(a-h,o-z)
common/com1/x(10,10)
call saisie
do 44 i=1,10
do 44 j=1,10
44 write(*,*) x(i,j)
end
subroutine saisie
implicit double precision(a-h,o-z)
common/com1/x(10,10)
do 45 i=1,10
do 45 j=1,10
45 x(i,j)=2.d0
return
end

SOS : après la compilation avec g77 sous linux voilà l'affichage:

Segmentation fault

qu'est ce que celà veut dire et quelle sera la structure correcte de ce programme pour qu'il ça marche (affiche le tableau x correctement en gardant tjs le common prog principale et la subroutine saisie.

c à d
program test

...........
common/com1/x(10,10)
call saisie
..............
..............
end
subroutine saisie
.......................
common/com1/x(10,10)
...................
...................
return
end
please help me !!!!

Merci pour vous tous.
Toug

tshirtman · Le 18/08/2007, à 00:14

oula je parle pas le fortran....

tu as essayé de mettre l'option -Wall a la compilation (warnings all)? Pour que g77 te disent ce qui pourrait ne pas aller.

si je comprends bien tu remplis la première ligne et la première colonne (ou tout le tableau?) d'un tableau de 10×10 avec la valeur 2.d0 (exa) avant de l'afficher.

tu devrait vérifier si par hazard ça ne marche pas mieux avec 0,9 au lieux des 1,10 dans tes "do" car si c'est comme en c, un tableau de 10 cases est indexé de 0 à 9...

Dernière modification par tshirtman (Le 18/08/2007, à 00:14)

Toug · Le 18/08/2007, à 11:06

Merci beaucoup à tous les responsables de ce site et en plus à Tshirtman :

I am sorry j' ai constaté que j'ai oublié la virgule càd au lieu de mettre
do i=1,10
j'ai mis do i=10

Merci
Votre Toug.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 11/08/2007, à 11:25

pb de memoire de programmation???

#2 Le 11/08/2007, à 14:21

Re : pb de memoire de programmation???

#3 Le 11/08/2007, à 17:55

Re : pb de memoire de programmation???

#4 Le 11/08/2007, à 18:04

Re : pb de memoire de programmation???

#5 Le 11/08/2007, à 18:20

Re : pb de memoire de programmation???

#6 Le 11/08/2007, à 19:32

Re : pb de memoire de programmation???

#7 Le 12/08/2007, à 13:35

Re : pb de memoire de programmation???

#8 Le 13/08/2007, à 01:20

Re : pb de memoire de programmation???

#9 Le 13/08/2007, à 08:14

Re : pb de memoire de programmation???

#10 Le 13/08/2007, à 10:10

Re : pb de memoire de programmation???

#11 Le 13/08/2007, à 10:13

Re : pb de memoire de programmation???

#12 Le 13/08/2007, à 19:28

Re : pb de memoire de programmation???

#13 Le 13/08/2007, à 20:44

Re : pb de memoire de programmation???

#14 Le 13/08/2007, à 21:05

Re : pb de memoire de programmation???

#15 Le 13/08/2007, à 21:34

Re : pb de memoire de programmation???

#16 Le 14/08/2007, à 11:17

Re : pb de memoire de programmation???

#17 Le 17/08/2007, à 11:56

Re : pb de memoire de programmation???

#18 Le 17/08/2007, à 12:06

Re : pb de memoire de programmation???

#19 Le 17/08/2007, à 12:15

Re : pb de memoire de programmation???

#20 Le 17/08/2007, à 12:31

Re : pb de memoire de programmation???

#21 Le 17/08/2007, à 13:44

Re : pb de memoire de programmation???

#22 Le 17/08/2007, à 13:56

Re : pb de memoire de programmation???

#23 Le 17/08/2007, à 19:46

Re : pb de memoire de programmation???

#24 Le 18/08/2007, à 00:14

Re : pb de memoire de programmation???

#25 Le 18/08/2007, à 11:06

Re : pb de memoire de programmation???

Pied de page des forums