Fuite de Memoires & Valgrind (linux)

Version imprimable

Bonjour,

voila je suis entrain de creer un program (qui utilise la librarie OpenCV)
Cependant j'ai remarqué (en utilisant la commande top) que ma RAM augmente continuellement.

Donc je me suis dit que j'avais une fuite de memoire... donc je me suis dit que je devrait essayer valgrind pour trouver cette fuite de memoire.

Le problème c'est qu'il me donne uniquement des message d'erreurs sur des parties de code qui sont appelé uniquement a la fin du programme.

Donc voici mes questions: Est-ce normal qu'un programme utilise de plus en plus de RAM (il n'y a aucun printf dans mon programme, et je n'ai aucune variable qui croit tout le temps dans mon code)

Ma deuxième question viens d'une des lignes a corriger selon valgrind

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
==12219==  Address 0x5b6a5bc is 12 bytes inside a block of size 24 free'd
==12219==    at 0x40246EA: operator delete(void*) (vg_replace_malloc.c:342)
==12219==    by 0x40C2824: __gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<std::string const, X7sParam*> > >::deallocate(std::_Rb_tree_node<std::pair<std::string const, X7sParam*> >*, unsigned) (new_allocator.h:98)
==12219==    by 0x40C2859: std::_Rb_tree<std::string, std::pair<std::string const, X7sParam*>, std::_Select1st<std::pair<std::string const, X7sParam*> >, std::less<std::string>, std::allocator<std::pair<std::string const, X7sParam*> > >::_M_put_node(std::_Rb_tree_node<std::pair<std::string const, X7sParam*> >*) (stl_tree.h:361)
==12219==    by 0x40C28BA: std::_Rb_tree<std::string, std::pair<std::string const, X7sParam*>, std::_Select1st<std::pair<std::string const, X7sParam*> >, std::less<std::string>, std::allocator<std::pair<std::string const, X7sParam*> > >::_M_destroy_node(std::_Rb_tree_node<std::pair<std::string const, X7sParam*> >*) (stl_tree.h:391)
==12219==    by 0x40C51B5: std::_Rb_tree<std::string, std::pair<std::string const, X7sParam*>, std::_Select1st<std::pair<std::string const, X7sParam*> >, std::less<std::string>, std::allocator<std::pair<std::string const, X7sParam*> > >::erase(std::_Rb_tree_iterator<std::pair<std::string const, X7sParam*> >) (stl_tree.h:1319)
==12219==    by 0x40C51EF: std::map<std::string, X7sParam*, std::less<std::string>, std::allocator<std::pair<std::string const, X7sParam*> > >::erase(std::_Rb_tree_iterator<std::pair<std::string const, X7sParam*> >) (stl_map.h:523)
==12219==    by 0x40C0548: X7sParamList::~X7sParamList() (X7sXmlParam.cpp:219)
==12219==    by 0x40C06D4: X7sXmlParamList::~X7sXmlParamList() (X7sXmlParam.cpp:302)
==12219==    by 0x4046B5F: X7sFGDetectorImpl::Release() (X7sFGDetector.cpp:152)
==12219==    by 0x40448BB: X7sVidSurvPipelineFG::~X7sVidSurvPipelineFG() (X7sVSPipelineFG.cpp:111)
==12219==    by 0x8048CD3: main (VidSurvVideo.cpp:77)
==12219==

Je ne suis pas sur de comprendre mais j'ai l'impression que je ne libère pas bien la mémoire, pour ces lignes d'exécution:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
 
X7sParamList::~X7sParamList() {
	X7sParam *param;
	m_mapID.clear();
	m_it=m_mapName.begin();
	while(m_it != m_mapName.end()) {
		param = (*m_it).second;
		if(param) delete param;
		m_mapName.erase(m_it);
		m_it++;
	}
}

Avec comme definition pour la classe

Code:

1
2
3
4
5
6
 
class X7sParamList {
private:
	std::map<std::string,X7sParam*> m_mapName;
	std::map<std::string,X7sParam*>::iterator m_it;
}

Voila et merci encore

05/06/2009, 16h10
koala01
Une petite question peut être idiote, mais ta classe X7sParamList (ou toute classe "associée" d'une manière ou d'un autre à X7sParamList) ne serait-elles pas copiable, par hasard :question:

Si oui, vérifie peut être
1. Le constructeur par copie et l'opérateur d'assignation de la classe X7sParamList
2. la manière dont la copie est appelée dans ton code, (utilisation de new X7sParamList(malist) :question)
3. si les variables utilisées pour la copie et / ou l'assignation qui utilisent des pointeurs sur des types X7sParamList dont la mémoire a été allouée dynamiquement sont correctement gérés (si à chaque new / new[] correspond bien un delte / delete[])
05/06/2009, 16h20
elraton

hummm je cois pas!

Je n'ai déclaré aucun constructeur par copie...
donc si je ne me trompe pas, il y a juste le constructeur par copie implicite.

Par contre est-ce que cela peut provoquer des erreurs au niveau d'une double desallocation! je ne sais pas. Cependant dans mon code je suis sur que je n'utilise jamais de:

X7sParamList list1;
X7sParamList list2 = list1;
X7sParamList list3 = X7sParamList();
05/06/2009, 16h40
koala01

Citation:

Envoyé par elraton

hummm je cois pas!

Je n'ai déclaré aucun constructeur par copie...
donc si je ne me trompe pas, il y a juste le constructeur par copie implicite.

Du coup, le compilateur crée automatiquement un constructeur par copie qui travaille "membre à membre"

Typiquement, dés que tu travailles avec de l'allocation dynamique et des "pointeurs bruts" pour un membre, il est conseillé soit de refuser purement et simplement la copie et l'assignation ( == de rendre la classe non copiable et non assignable), soit mettre en place ses propres constructeurs par copie et opérateur d'affectation...

Citation:

Par contre est-ce que cela peut provoquer des erreurs au niveau d'une double desallocation! je ne sais pas.

Et je te confirme que c'est effectivement le risque si une copie ou une affectation est effectuée et que tu n'a pas redéfini les constructeur par copie et opérateur d'affectation :aie:
Cependant dans mon code je suis sur que je n'utilise jamais de:

Citation:

X7sParamList list1;
X7sParamList list2 = list1;
X7sParamList list3 = X7sParamList();

Attention, la copie peut être appelée dans bien d'autres cas, dont, principalement, le passage d'un argument par valeur plutôt que par référence...

Cependant, dans ce cas, le risque principal est effectivement la double désallocation de la mémoire (qui est quand même tout aussi embêtant que la fuite mémoire :P)

Si tu es sur que la gestion de la mémoire au niveau de tes classes personnelles est correct (ce qui semble déjà "mal barré" si tu a gardé le constructeur par copie et l'opérateur d'assignation par défaut), tu peux sans doute essayer de voir du coté de la gestion des ressources fournies par OpenCV...

Oky du coup j'ai interet a le faire moi meme ce constructeur par copie :(
Meme si il est vide c'est quand meme mieux qu'une double desallocation.

Code:

1
2
3
4
5
 
X7sParamList::X7sParamList(X7sParamList const& copy)
{
	cerr << "X7sParamList::X7sParamList(const& copy) Should not use the copy constructor" << endl;
}

Cependant durant l'execution de mon code je n'ai jamais ce message qui apparait!

Sinon je voulais savoir si c'était normal d'avoir ce genre d'erreur avec valgring:

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
 
==14680== 156 (36 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 46 of 142
==14680==    at 0x4025D2E: malloc (vg_replace_malloc.c:207)
==14680==    by 0x462DDC0: (within /lib/tls/i686/cmov/libc-2.8.90.so)
==14680==    by 0x462E6F5: __nss_database_lookup (in /lib/tls/i686/cmov/libc-2.8.90.so)
==14680==    by 0x5E2EF5B: ???
==14680==    by 0x5E2FCBE: ???
==14680==    by 0x45D4CB1: getpwnam_r (in /lib/tls/i686/cmov/libc-2.8.90.so)
==14680==    by 0x528E765: (within /usr/lib/libglib-2.0.so.0.1800.2)
==14680==    by 0x529025C: g_get_home_dir (in /usr/lib/libglib-2.0.so.0.1800.2)
==14680==    by 0x4E2D537: (within /usr/lib/libgtk-x11-2.0.so.0.1400.4)
==14680==    by 0x4E2FF0A: (within /usr/lib/libgtk-x11-2.0.so.0.1400.4)
==14680==    by 0x4DE2BE4: (within /usr/lib/libgtk-x11-2.0.so.0.1400.4)
==14680==    by 0x526883C: g_option_context_parse (in /usr/lib/libglib-2.0.so.0.1800.2)
==14680== 
==14680== 
==14680== 60 bytes in 1 blocks are possibly lost in loss record 56 of 142
==14680==    at 0x4025E4C: realloc (vg_replace_malloc.c:429)
==14680==    by 0x5261C69: g_realloc (in /usr/lib/libglib-2.0.so.0.1800.2)
==14680==    by 0x5FF6670: ORBit_realloc_tcval (in /usr/lib/libORBit-2.so.0.1.0)
==14680==    by 0x5FFAC76: ORBit_sequence_append (in /usr/lib/libORBit-2.so.0.1.0)
==14680==    by 0x5FC5B81: bonobo_activation_init_activation_env (in /usr/lib/libbonobo-activation.so.4.0.0)
==14680==    by 0x5FC9DD3: bonobo_activation_orb_init (in /usr/lib/libbonobo-activation.so.4.0.0)
==14680==    by 0x5FCA21D: bonobo_activation_init (in /usr/lib/libbonobo-activation.so.4.0.0)
==14680==    by 0x5F7DD5C: bonobo_init_full (in /usr/lib/libbonobo-2.so.0.0.0)
==14680==    by 0x5F7DF0B: bonobo_init (in /usr/lib/libbonobo-2.so.0.0.0)
==14680==    by 0x5E18989: (within /usr/lib/gtk-2.0/modules/libatk-bridge.so)
==14680==    by 0x4DFB5AC: (within /usr/lib/libgtk-x11-2.0.so.0.1400.4)
==14680==    by 0x51F3AEB: g_cclosure_marshal_VOID__PARAM (in /usr/lib/libgobject-2.0.so.0.1800.2)
==14680== 
==14680== 
==14680== 122 bytes in 8 blocks are possibly lost in loss record 71 of 142
==14680==    at 0x4025D2E: malloc (vg_replace_malloc.c:207)
==14680==    by 0x5261D83: g_malloc (in /usr/lib/libglib-2.0.so.0.1800.2)
==14680==    by 0x5FF676F: ORBit_alloc_string (in /usr/lib/libORBit-2.so.0.1.0)
==14680==    by 0x5FF6438: CORBA_string_dup (in /usr/lib/libORBit-2.so.0.1.0)
==14680==    by 0x5FFAAAC: ORBit_copy_value_core (in /usr/lib/libORBit-2.so.0.1.0)
==14680==    by 0x5FFA7EB: ORBit_copy_value_core (in /usr/lib/libORBit-2.so.0.1.0)
==14680==    by 0x5FFAC3E: ORBit_sequence_append (in /usr/lib/libORBit-2.so.0.1.0)
==14680==    by 0x5FC5B81: bonobo_activation_init_activation_env (in /usr/lib/libbonobo-activation.so.4.0.0)
==14680==    by 0x5FC9DD3: bonobo_activation_orb_init (in /usr/lib/libbonobo-activation.so.4.0.0)
==14680==    by 0x5FCA21D: bonobo_activation_init (in /usr/lib/libbonobo-activation.so.4.0.0)
==14680==    by 0x5F7DD5C: bonobo_init_full (in /usr/lib/libbonobo-2.so.0.0.0)
==14680==    by 0x5F7DF0B: bonobo_init (in /usr/lib/libbonobo-2.so.0.0.0)
==14680== 
==14680== 
==14680== 148 bytes in 1 blocks are definitely lost in loss record 75 of 142
==14680==    at 0x4025D2E: malloc (vg_replace_malloc.c:207)
==14680==    by 0x420CB29: (within /usr/lib/libcxcore.so.2.0.0)
==14680== 
==14680== 
==14680== 1,120 bytes in 32 blocks are possibly lost in loss record 107 of 142
==14680==    at 0x4023DE2: calloc (vg_replace_malloc.c:397)
==14680==    by 0x5261D0B: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1800.2)
==14680==    by 0x5200423: (within /usr/lib/libgobject-2.0.so.0.1800.2)
==14680==    by 0x5200495: (within /usr/lib/libgobject-2.0.so.0.1800.2)
==14680==    by 0x5204171: g_type_register_fundamental (in /usr/lib/libgobject-2.0.so.0.1800.2)
==14680==    by 0x520ED3E: (within /usr/lib/libgobject-2.0.so.0.1800.2)
==14680==    by 0x5202BDC: g_type_init_with_debug_flags (in /usr/lib/libgobject-2.0.so.0.1800.2)
==14680==    by 0x5202C61: g_type_init (in /usr/lib/libgobject-2.0.so.0.1800.2)
==14680==    by 0x506D8F2: gdk_pre_parse_libgtk_only (in /usr/lib/libgdk-x11-2.0.so.0.1400.4)
==14680==    by 0x4DE2D86: (within /usr/lib/libgtk-x11-2.0.so.0.1400.4)
==14680==    by 0x5268304: g_option_context_parse (in /usr/lib/libglib-2.0.so.0.1800.2)
==14680==    by 0x4DE2871: gtk_parse_args (in /usr/lib/libgtk-x11-2.0.so.0.1400.4)
==14680== 
==14680== 
==14680== 5,760 bytes in 8 blocks are possibly lost in loss record 124 of 142
==14680==    at 0x4023C4A: memalign (vg_replace_malloc.c:460)
==14680==    by 0x540AE10: av_malloc (in /usr/lib/i686/cmov/libavutil.so.49.6.0)
==14680== 
==14680== 
==14680== 70,712 bytes in 57 blocks are possibly lost in loss record 136 of 142
==14680==    at 0x4023C4A: memalign (vg_replace_malloc.c:460)
==14680==    by 0x4023CFE: posix_memalign (vg_replace_malloc.c:569)
==14680==    by 0x5277352: (within /usr/lib/libglib-2.0.so.0.1800.2)
==14680==    by 0x5278B01: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1800.2)
==14680==    by 0x52328AE: g_array_sized_new (in /usr/lib/libglib-2.0.so.0.1800.2)
==14680==    by 0x52329C6: g_array_new (in /usr/lib/libglib-2.0.so.0.1800.2)
==14680==    by 0x5284323: g_static_private_set (in /usr/lib/libglib-2.0.so.0.1800.2)
==14680==    by 0x521C1B9: g_module_supported (in /usr/lib/libgmodule-2.0.so.0.1800.2)
==14680==    by 0x4DFBB67: (within /usr/lib/libgtk-x11-2.0.so.0.1400.4)
==14680==    by 0x4DFC184: (within /usr/lib/libgtk-x11-2.0.so.0.1400.4)
==14680==    by 0x4DE2C16: (within /usr/lib/libgtk-x11-2.0.so.0.1400.4)
==14680==    by 0x526883C: g_option_context_parse (in /usr/lib/libglib-2.0.so.0.1800.2)
==14680== 
==14680== 
==14680== 718,272 bytes in 43 blocks are possibly lost in loss record 140 of 142
==14680==    at 0x4023C4A: memalign (vg_replace_malloc.c:460)
==14680==    by 0x540AEF7: av_mallocz (in /usr/lib/i686/cmov/libavutil.so.49.6.0)
==14680== 
==14680== 
==14680== 12,051,648 (11,559,168 direct, 492,480 indirect) bytes in 692 blocks are definitely lost in loss record 142 of 142
==14680==    at 0x4023C4A: memalign (vg_replace_malloc.c:460)
==14680==    by 0x540AEF7: av_mallocz (in /usr/lib/i686/cmov/libavutil.so.49.6.0)

Visiblement ca ne viens pas de ma librarie :calim2:

Citation:

Envoyé par elraton

Oky du coup j'ai interet a le faire moi meme ce constructeur par copie :(
Meme si il est vide c'est quand meme mieux qu'une double desallocation.

En fait, le mieux est sans doute:

Soit de rendre ta classe non copiable et non assignable, en déclarant sans les implémenter le constructeur par copie et l'opérateur d'assignation dans l'accessibilité privée ou en la faisant hériter (de manière privée) de boost::noncopyable

Soit de t'assurer que la copie ne posera pas de problème, en recourant, par exemple au shared_ptr

Car

Citation:

Code:

1
2
3
4
5
 
X7sParamList::X7sParamList(X7sParamList const& copy)
{
	cerr << "X7sParamList::X7sParamList(const& copy) Should not use the copy constructor" << endl;
}

me semble presque plus dangereux, étant donné que, s'il est appelé, tu aura effectivement une sortie sur cerr (mais est-il accessible :question:) mais... ne fera absolument pas ce qu'il est sensé faire:

Il est sensé te donner une copie de ta X7sParamList et te donne en réalité... une X7sParamList vide :aie:

Citation:

Cependant durant l'execution de mon code je n'ai jamais ce message qui apparait!

Sinon je voulais savoir si c'était normal d'avoir ce genre d'erreur avec valgring:

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
 
==14680== 156 (36 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 46 of 142
==14680==    at 0x4025D2E: malloc (vg_replace_malloc.c:207)
==14680==    by 0x462DDC0: (within /lib/tls/i686/cmov/libc-2.8.90.so)
==14680==    by 0x462E6F5: __nss_database_lookup (in /lib/tls/i686/cmov/libc-2.8.90.so)
==14680==    by 0x5E2EF5B: ???
==14680==    by 0x5E2FCBE: ???
==14680==    by 0x45D4CB1: getpwnam_r (in /lib/tls/i686/cmov/libc-2.8.90.so)
==14680==    by 0x528E765: (within /usr/lib/libglib-2.0.so.0.1800.2)
==14680==    by 0x529025C: g_get_home_dir (in /usr/lib/libglib-2.0.so.0.1800.2)
==14680==    by 0x4E2D537: (within /usr/lib/libgtk-x11-2.0.so.0.1400.4)
==14680==    by 0x4E2FF0A: (within /usr/lib/libgtk-x11-2.0.so.0.1400.4)
==14680==    by 0x4DE2BE4: (within /usr/lib/libgtk-x11-2.0.so.0.1400.4)
==14680==    by 0x526883C: g_option_context_parse (in /usr/lib/libglib-2.0.so.0.1800.2)
==14680== 
==14680== 
==14680== 60 bytes in 1 blocks are possibly lost in loss record 56 of 142
==14680==    at 0x4025E4C: realloc (vg_replace_malloc.c:429)
==14680==    by 0x5261C69: g_realloc (in /usr/lib/libglib-2.0.so.0.1800.2)
==14680==    by 0x5FF6670: ORBit_realloc_tcval (in /usr/lib/libORBit-2.so.0.1.0)
==14680==    by 0x5FFAC76: ORBit_sequence_append (in /usr/lib/libORBit-2.so.0.1.0)
==14680==    by 0x5FC5B81: bonobo_activation_init_activation_env (in /usr/lib/libbonobo-activation.so.4.0.0)
==14680==    by 0x5FC9DD3: bonobo_activation_orb_init (in /usr/lib/libbonobo-activation.so.4.0.0)
==14680==    by 0x5FCA21D: bonobo_activation_init (in /usr/lib/libbonobo-activation.so.4.0.0)
==14680==    by 0x5F7DD5C: bonobo_init_full (in /usr/lib/libbonobo-2.so.0.0.0)
==14680==    by 0x5F7DF0B: bonobo_init (in /usr/lib/libbonobo-2.so.0.0.0)
==14680==    by 0x5E18989: (within /usr/lib/gtk-2.0/modules/libatk-bridge.so)
==14680==    by 0x4DFB5AC: (within /usr/lib/libgtk-x11-2.0.so.0.1400.4)
==14680==    by 0x51F3AEB: g_cclosure_marshal_VOID__PARAM (in /usr/lib/libgobject-2.0.so.0.1800.2)
==14680== 
==14680== 
==14680== 122 bytes in 8 blocks are possibly lost in loss record 71 of 142
==14680==    at 0x4025D2E: malloc (vg_replace_malloc.c:207)
==14680==    by 0x5261D83: g_malloc (in /usr/lib/libglib-2.0.so.0.1800.2)
==14680==    by 0x5FF676F: ORBit_alloc_string (in /usr/lib/libORBit-2.so.0.1.0)
==14680==    by 0x5FF6438: CORBA_string_dup (in /usr/lib/libORBit-2.so.0.1.0)
==14680==    by 0x5FFAAAC: ORBit_copy_value_core (in /usr/lib/libORBit-2.so.0.1.0)
==14680==    by 0x5FFA7EB: ORBit_copy_value_core (in /usr/lib/libORBit-2.so.0.1.0)
==14680==    by 0x5FFAC3E: ORBit_sequence_append (in /usr/lib/libORBit-2.so.0.1.0)
==14680==    by 0x5FC5B81: bonobo_activation_init_activation_env (in /usr/lib/libbonobo-activation.so.4.0.0)
==14680==    by 0x5FC9DD3: bonobo_activation_orb_init (in /usr/lib/libbonobo-activation.so.4.0.0)
==14680==    by 0x5FCA21D: bonobo_activation_init (in /usr/lib/libbonobo-activation.so.4.0.0)
==14680==    by 0x5F7DD5C: bonobo_init_full (in /usr/lib/libbonobo-2.so.0.0.0)
==14680==    by 0x5F7DF0B: bonobo_init (in /usr/lib/libbonobo-2.so.0.0.0)
==14680== 
==14680== 
==14680== 148 bytes in 1 blocks are definitely lost in loss record 75 of 142
==14680==    at 0x4025D2E: malloc (vg_replace_malloc.c:207)
==14680==    by 0x420CB29: (within /usr/lib/libcxcore.so.2.0.0)
==14680== 
==14680== 
==14680== 1,120 bytes in 32 blocks are possibly lost in loss record 107 of 142
==14680==    at 0x4023DE2: calloc (vg_replace_malloc.c:397)
==14680==    by 0x5261D0B: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1800.2)
==14680==    by 0x5200423: (within /usr/lib/libgobject-2.0.so.0.1800.2)
==14680==    by 0x5200495: (within /usr/lib/libgobject-2.0.so.0.1800.2)
==14680==    by 0x5204171: g_type_register_fundamental (in /usr/lib/libgobject-2.0.so.0.1800.2)
==14680==    by 0x520ED3E: (within /usr/lib/libgobject-2.0.so.0.1800.2)
==14680==    by 0x5202BDC: g_type_init_with_debug_flags (in /usr/lib/libgobject-2.0.so.0.1800.2)
==14680==    by 0x5202C61: g_type_init (in /usr/lib/libgobject-2.0.so.0.1800.2)
==14680==    by 0x506D8F2: gdk_pre_parse_libgtk_only (in /usr/lib/libgdk-x11-2.0.so.0.1400.4)
==14680==    by 0x4DE2D86: (within /usr/lib/libgtk-x11-2.0.so.0.1400.4)
==14680==    by 0x5268304: g_option_context_parse (in /usr/lib/libglib-2.0.so.0.1800.2)
==14680==    by 0x4DE2871: gtk_parse_args (in /usr/lib/libgtk-x11-2.0.so.0.1400.4)
==14680== 
==14680== 
==14680== 5,760 bytes in 8 blocks are possibly lost in loss record 124 of 142
==14680==    at 0x4023C4A: memalign (vg_replace_malloc.c:460)
==14680==    by 0x540AE10: av_malloc (in /usr/lib/i686/cmov/libavutil.so.49.6.0)
==14680== 
==14680== 
==14680== 70,712 bytes in 57 blocks are possibly lost in loss record 136 of 142
==14680==    at 0x4023C4A: memalign (vg_replace_malloc.c:460)
==14680==    by 0x4023CFE: posix_memalign (vg_replace_malloc.c:569)
==14680==    by 0x5277352: (within /usr/lib/libglib-2.0.so.0.1800.2)
==14680==    by 0x5278B01: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1800.2)
==14680==    by 0x52328AE: g_array_sized_new (in /usr/lib/libglib-2.0.so.0.1800.2)
==14680==    by 0x52329C6: g_array_new (in /usr/lib/libglib-2.0.so.0.1800.2)
==14680==    by 0x5284323: g_static_private_set (in /usr/lib/libglib-2.0.so.0.1800.2)
==14680==    by 0x521C1B9: g_module_supported (in /usr/lib/libgmodule-2.0.so.0.1800.2)
==14680==    by 0x4DFBB67: (within /usr/lib/libgtk-x11-2.0.so.0.1400.4)
==14680==    by 0x4DFC184: (within /usr/lib/libgtk-x11-2.0.so.0.1400.4)
==14680==    by 0x4DE2C16: (within /usr/lib/libgtk-x11-2.0.so.0.1400.4)
==14680==    by 0x526883C: g_option_context_parse (in /usr/lib/libglib-2.0.so.0.1800.2)
==14680== 
==14680== 
==14680== 718,272 bytes in 43 blocks are possibly lost in loss record 140 of 142
==14680==    at 0x4023C4A: memalign (vg_replace_malloc.c:460)
==14680==    by 0x540AEF7: av_mallocz (in /usr/lib/i686/cmov/libavutil.so.49.6.0)
==14680== 
==14680== 
==14680== 12,051,648 (11,559,168 direct, 492,480 indirect) bytes in 692 blocks are definitely lost in loss record 142 of 142
==14680==    at 0x4023C4A: memalign (vg_replace_malloc.c:460)
==14680==    by 0x540AEF7: av_mallocz (in /usr/lib/i686/cmov/libavutil.so.49.6.0)

Visiblement ca ne viens pas de ma librarie :calim2:

Sur ce coup là, je vais laisser répondre ceux qui connaisse valgrind ;)

Okay, je vais opter pour la solution suivante:
Code:

1 2 3 4 5 6 class X7sParamList { private: X7sParamList(const X7sParamList& copy); // declared private, but not defined, to prevent copying X7sParamList& operator=(const X7sParamList&); // declared private, but not defined, to prevent copying }
Mais j'ai un question au sujet des constructeur par copie:
je voulais savoir si X7sParamList(const X7sParamList& copy); etait equivalent a X7sParamList(X7sParamList const& copy);

05/06/2009, 18h05
koala01

Oui, c'est équivalent dans les faits...

Dans la théorie, tu as d'un coté une déclaration qui suit la règle générale (le mot clé const s'applique à ce qui le précède) et de l'autre une déclaration qui suit l'exception (mais si rien ne précède le mot clé const, il s'applique à ce qui suit)