pb de memoire ou erreur de programmation?

Version imprimable

11/08/2007, 12h32
nina2007

pb de memoire ou erreur de programmation?

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
11/08/2007, 14h11
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.
11/08/2007, 19h37
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??????
11/08/2007, 19h42
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.
11/08/2007, 19h45
nina2007

suite du précedent

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)
11/08/2007, 19h51
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:cry:
11/08/2007, 19h54
nina2007

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

pourquoi ce message "Program exited normally"????
11/08/2007, 20h04
d'Oursse

si ton programme a des arguments (par exemple ./mon_prog option1 option2), utilise gdb ainsi:

gdb ./mon_prog
> run options1 opion2
11/08/2007, 20h23
nina2007

voici ce que j'obtiens:
le pb est donc dans la methode construire_regles, n'est ce pas?

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---
11/08/2007, 23h48
d'Oursse

en general, le probleme se situe sur la frame #0 (la premiere a etre affichee). Les autres, c'est pour tracer toutes les instructions menant au seg fault. C'est utile car quelque fois, le probleme se situe en amont de la frame #0.

ici, le seg fault est dans le malloc. Ce qui ne devrait jamais arriver... sauf si tu as gere la memoire que tu as allouee vraiment comme un cochon :mrgreen:

la, je ne peux rien dire de plus sans voir le code. Deja, te semble-t-il normal que construire_regles soit appelee si souvent ?

Au passage, concernant le backtrace, n'hesite pas a appuyer sur retrn pour voir la totalite des frames (tu t'es arrete a la frame #12)
13/08/2007, 11h43
nina2007

construire_regles() est une fonction recursive c pour ça qu'elle est aplée si souvent
13/08/2007, 11h46
f-k-z

Yop,
nina2007, pourrais tu s'il te pplait nous montrer ta source pour que l'on puisse voir d'ou cela vient?

cdlt,

F-k-z

Au fait le code est complexe et assez long mais voici la methode ou ça existe le pb, c la methode construire_regles ds laquelle je parcours un arbre (j'utilise une file pour sauvegarder les differents élements de l'arbre et pour que je puisse retourner le frére, le fils, etc)

any help?

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
void tree_GMF::construire_regles(element* e, int i)
{
 
element *ei=new element;
element *tete=new element;
element *es=new element;
element *tete_file=new element;
element *courant=new element;
bool existe,dernier;
int conclusion,indice;
bool trouve=false;
if(e!=NULL)
{
p1.push(e);
 
 
 if(i==1)
  { while (!f1.empty())
  {f1.pop();}
 f1.push(e);
 i++;
 }
 else
 { if (!f1.empty())
    {
    f1.push(e);}
    else
    {
 
    f2.push(e);}
 }
 
ei=e->retourner_fils();
  while(ei!=NULL)
    {
    if(!f1.empty())
       {
       while(!f1.empty())
       {
       tete_file=f1.front();
         if(tete_file->retourner_fils())
       {
      tete_file->afficher();cout<<" ";
            f2.push(tete_file);
       f1.pop();
       }
          else
	  {f2.push(tete_file);
           f1.pop();
 
 
	  }
 
 
      }
       }
       else
       {
 
   while(!f2.empty())
       {
 
 
       tete_file=f2.front();
       if(tete_file->retourner_fils())
       {
       tete_file->afficher();cout<<" ";
           f1.push(tete_file);
       f2.pop();
       }
          else
	  {f1.push(tete_file);
       f2.pop();
 
 
	  }
 
       }
       }
      cout<<"derni ";
       ei->afficher();
 
     existe=false;
 
           for(set<int>::iterator i=id_fermetures.begin();i!=id_fermetures.end();i++)
            {
               if(ei->retourner_id_fermeture()==(int)*i)
	       {existe=true;}
	       }
	       if(existe)
	       {cout<<"existe\n";
	       bit_vector premisse;
	       regle_supp reg;
                  courant=ei;
	       dernier=true;
	         multimap<int, int>::iterator l = fermeture_items.find(ei->retourner_id_fermeture());
 
                 for(multimap<int, int>::iterator l = fermeture_items.find(ei->retourner_id_fermeture());(*l).first==ei->retourner_id_fermeture();l++)
 
         {
                     		 conclusion=(*l).second;
 
                                        while (courant!=NULL)
					{cout<<"courant ";courant->afficher();
					 if(dernier)
					 {
					 for( int k=0;k<=courant->retourner_item()-1;k++)
			                     {premisse.insert(premisse.end(),false);
					     }
 
 
                                              premisse.insert(premisse.end(),true);
 
					      dernier=false;
 
	                                  }
					  else
					  {indice=0;
 
						  premisse[courant->retourner_item()]=true;
 
 
 
 
					  }
                                           courant=courant->retourner_pere();
					   }
 
 
 
                           cout<<"\nje vais inserer "<<conclusion;
		           cout<<"et la premisse ";
			afficher_vecteur_bit(premisse);cout<<"\n";
			reg.supp=0;
			reg.regle=premisse;
 
 
regles.insert(pair<int,regle_supp>(conclusion,reg));
 
 trouve=false;
 
 
			}
 
 
 
 
 
 
 
 
 
	       }
	       else
	       {cout<<"not existe";
	       }
 
 
 
     cout<<"\n";
       ei=ei->retourner_frere();
    }
    e=e->retourner_fils();
 
}
  if(e!=NULL)
        {construire_regles(e,i);}
 
else
{  if(!p1.empty())
   { //cout<<" je suis ici ";
    tete=p1.top();
    p1.pop();
    es=tete->retourner_frere();
 
 
    if(es!=NULL)
    {
    construire_regles(es,i);
}
 
 
      else
       {if(!p1.empty())
       {
       tete=p1.top();
        p1.pop();
        es=tete->retourner_frere();
         if(es!=NULL)
	 { while(!p1.empty())
	   {tete=p1.top();
	    p2.push(tete);
	    p1.pop();
           }
	   while(!f1.empty())
	   {f1.pop();}
 
	   while(!p2.empty())
	   {tete=p2.top();
	    p1.push(tete);
            f1.push(tete);
	    p2.pop();
	    }
	    while(!f2.empty())
	    {f2.pop();}
	 construire_regles(es,i);}
 
             }
 
 
 
        }
 
   }
 
  else
   {
   exit(0);
   }
}
 
 
 
}

13/08/2007, 20h30
nina2007

nouvelle tentative

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

qu'est ce que ça signifie? pb dans un fichier?

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 ()
14/08/2007, 07h28
d'Oursse

ma reponse est la meme : ca ne doit pas arriver sauf si tu geres mal la memoire.

ensuite, pour ton code, edite ton post en utilisant la balise "code" et en indentant la fonction, elle est illisible.

enfin, pour ton dernier backtrace, tu as compile sans -g, donc les infos que tu donnes sont inutiles.

pour ma part, j'essaie d'eviter, quand c'est possible de faire autrement assez silmplement, les fonctions recursives. A priori, ca concerne un arbre, donc c'est raisonnable, je pense.