g-free ( pixbuf ) ?

bonjour j'ai développé une petite application de "traitement" de l'image et j'ai quelques soucis :

1) j'utilise des pixbuf....mais je ne les libère jamais faute de connaissances (d'où mon titre), comment faire?

2) ça concerne moins le gtk mais j'aimerais "séparer" ma source en 4 fichiers et je ne vois pas comment faire. On m'a parler de makefile mais je ne sais pas comment gérer les variables de compilation, y a -t- il un bon tuto qui traine (accessible surtout).

PS : si je ne répond pas vite c'est parce que je n'ai pas le net chez moi.

Salut !

Pour ta question concernant les GdkPixbuf, tu dois utiliser g_object_unref pour libérer les images de types GdkPixbuf et GdkPixmap !

merci beaucoup!!:D :D :D

Petite question sur g_object_unref :
Est-ce utile de libérer la mémoire d'un pixbuf déclaré dans une fonction, ou c'est fait automatiquement quand elle se termine ?

Salut, avec quoi le pixbuf est-il créé/initialisé ? Cela peut dépendre je pense mais avec les fonctions comme gdk_pixbuf_new_from_file, il est précisé:

Citation:

A newly-created pixbuf with a reference count of 1, ...

Je ne suis pas un spécialiste de cette partie de la lib je dois avouer mais j'en conclu qu'il est préférable dans ce cas d'utiliser la fonction g_object_unref pour faire tomber le nombre de références à 0 ce qui permettra à la bibliothèque de libérer elle-même l'objet ;)

Citation:

Envoyé par Franck.H

Salut, avec quoi le pixbuf est-il créé/initialisé ? Cela peut dépendre je pense mais avec les fonctions comme gdk_pixbuf_new_from_file, il est précisé:

Je ne suis pas un spécialiste de cette partie de la lib je dois avouer mais j'en conclu qu'il est préférable dans ce cas d'utiliser la fonction g_object_unref pour faire tomber le nombre de références à 0 ce qui permettra à la bibliothèque de libérer elle-même l'objet ;)

En fait souvent pour le travail sur l'image ou récupération d'info (seuillage, récup de valeurs de pixels etc ...), je travail dans ma fonction avec une copie du pixbuf ( gdk_pixbuf_copy() ) histoire que le pixbuf d'origine (affiché à l'écran), ne soit pas modifié.
Jvais refaire un tour du coté du site de l'API ...

Autre question, dans ma fonction je récupère un pixbuf par argument, et je le fait pointer vers un autre pixbuf. Est ce que la mémoire de l'ancien pixbuf, (qui n'est donc plus pointé par rien) est vidé ou faut il le faire (comme le garbage collector en java)

Citation:

Envoyé par Acivurt

En fait souvent pour le travail sur l'image ou récupération d'info (seuillage, récup de valeurs de pixels etc ...), je travail dans ma fonction avec une copie du pixbuf ( gdk_pixbuf_copy() ) histoire que le pixbuf d'origine (affiché à l'écran), ne soit pas modifié.

C'est le même topo: g_object_unref ;)

Citation:

Envoyé par Acivurt

Autre question, dans ma fonction je récupère un pixbuf par argument, et je le fait pointer vers un autre pixbuf. Est ce que la mémoire de l'ancien pixbuf, (qui n'est donc plus pointé par rien) est vidé ou faut il le faire (comme le garbage collector en java)

Bin si c'est un argument, il faut très certainement libérer "l'ancier pixbuf" car ce n'est qu'un pointeur que tu passes, sauf éventuellement si tu transmet l'adresse de ce pixbuf à la fonction par le biais d'un pointeur sur pointeur auquel cas tu change le pointeur de ton pixbuf mais là je ne saurais te dire, je pense que dans ce cas, il serait plus sage d'appeler un g_object_unref puis de faire pointer ton pointeur sur le nouveau pixbuf.

Citation:

Envoyé par Franck.H

je pense que dans ce cas, il serait plus sage d'appeler un g_object_unref puis de faire pointer ton pointeur sur le nouveau pixbuf.

Dans quel cas le premier (pointeur) ou le deuxième (adresse du pixbuf)
:aie: lol en fait c'est la deuxième solution que j'utilise (c.f forum sur le (void **)&pixbuf ...), je passe effectivement l'adresse du pixbuf en double pointeur et non le pointeur pixbuf lui même ... donc c'est bon c'est ça ?
De toute, je pense que je vais au moins rajouter des unref partout ou j'ai des pixbuf local (locaux ??), mais c'est bizarre car par exemple, dans le programme je compare disons plusieurs centaines d'images, dans des boucles où à chaque fois je récupère un pixbuf via gdk_pixbuf_new_from_file, va falloir que je unref à chaque fin d'itération, ca va pas me ralentir le bouzin tt ça ?
En fait, pour l'instant aucun problème de mémoire, mais ça m'intrigue de pas savoir que deviennent mes pixbuf ...
Ya pas des logiciels permettant de savoir tt ca ?

Merci bien en tt cas pour tt tes réponses ... :king:

Citation:

Envoyé par Acivurt

...en double pointeur

Pas double pointeur mais pointeur sur pointeur :mouarf: :aie:

Je ne sais pas trop GTK fait la libération automatiquement si on ne dispose plus de référence (un pointeur) sur un objet donc, je pour éviter une surconsommation de mémoire, je pense qu'il est préférable de faire des unref. A moins que quelqu'un passe dans le coin est lève le doute ;)

Sinon, si tu test plusieurs centaines d'images et que ta mémoire ne s'en trouve pas saturée au bout d'un moment je pense que ca se fait automatiquement mais là encore je ne fait que supposer :aie:

Citation:

Envoyé par Franck.H

Pas double pointeur mais pointeur sur pointeur :mouarf: :aie:

lol dslé :oops:
Bref, je me réponds à moi même, j'ai matté le moniteur système et après chaque pression de mon boutton de traitement, 30 Mo en plus sur la ram, et qui semble pas s'en aller :aie: , après 50 pressions mon programme prend plus de 500 Mo, je vais concurrencer oblivion bientôt :mouarf:
Je pense que je vois rien comme ralentissement car j'ai 2 Go, mais des unref s'imposent, il me semble
Je fait le necessaire et je reposterais histoire de rendre compte de la gestion mémoire après , et que nos suppositions tendent plus vers des affirmations ;)

tu peux utiliser valgrind aussi pour profiler ton programme et voir ce qu'il se passe
http://valgrind.org/

Il faut faire les g_object_unref sur les pixbuf, sauf pour les fonctions pour lesquelles la doc de gtk+ dit le contraire, mais ça doit être bien rare. gtk+ libère uniquement de la mémoire quand le compteur de référence tombe à 0. Et il ne touche pas aux références qui t'appartiennent, heureusement. Donc par défaut, si tu fais pas de g_object_unref, la mémoire ne sera jamais libérée.
Et à ta place, je m'inquiéterai pas de l'impact de perf de g_object_unref dans ta boucle si à chaque itération tu fais un gdk_pixbuf_new_from_file, le temps de libération de la mémoire sera complètement négligeable par rapport à la lecture sur disque et la décompression de l'image.

Citation:

Envoyé par teuf13

Donc par défaut, si tu fais pas de g_object_unref, la mémoire ne sera jamais libérée.

+10 :king: après test au lieu de 30 Mo rajouté en RAM par calcul, j'ai reussi à passer à seulement (mais encore trop :( ) 10 Mo soit 20 Mo d'économisés par traitement :yaisse2: . J'ai fait gaffe de unref à peu près tous mes pixbufs et pixmap locaux. C'est donc confirmé GTK ne libère QUE si la ref est à 0.
Mais j'arrive toujours pas à savoir c'est quoi ces 10 Mo qui restent en RAM à chaque calcul.
mes malloc sont tous free après utilisation, ainsi que mes objets Gdk, et je pense pas allouer dynamiquement d'autres portions de mémoire... J'ai installé Valgrind, mais j'avoue avoir un peu de mal malgré le man. Il me fait un rapport que au lancement du prog et pas pour les calculs après le lancement...

Merci en tt cas à tous !

Salut

Citation:

Envoyé par Acivurt

Il me fait un rapport que au lancement du prog et pas pour les calculs après le lancement...

Ça laisse penser à un processus qui se fork et dont les fils font le calcul ;)

Regarde du côté de l'option --trace-children=yes. Chaque ligne écrite par valgrind commence par ==pid==, ça permet de s'y retrouver.

Bon debug'

sinon tu peux installer une front end pour valgrind cela sera plus pratique pour
s'y retrouver , genre alleyoop ou autre

http://valgrind.org/downloads/guis.html

Merci à vous 2 !

J'ai rajouté l'argument pour les processus enfants et installé l'interface graphique (c'est plus clair !), mais rien ni fait.
En fait, j'ai l'impression qu'il me donne qu'un rapport des erreurs mémoires, et moi je voudrais en fait connaitre concrètement comment mon programme alloue et utilise la mémoire, pour savoir pourquoi un de mes traitements me rajoute 10 Mo à chaque utilisation sans les rendre :evilred: . J'ai pas spécialement d'erreurs de mémoire (la preuve valgrind bronche pas lors de l'appel de la fonction), mais je veux savoir ce qui se passe ! Ya une option qui permet ça ?

Il faut lancer valgrind avec --leak-check=full pour qu'à la fin de ton programme il te fasse des stats sur la mémoire que tu as leakée.

Ahh OK !
Je pense cette fois avoir un rapport ... mais après c'est pas super "compréhensible", je vois des adresses, ma fonction, mais j'ai du mal à trier ...
Je vais y jeter un oeil plus attentif ce soir.

Voilà la fin du code à titre indicatif, si vous trouver qqchose de bizarre

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
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
==15440== 
==15440== 
==15440== 4,800 bytes in 30 blocks are still reachable in loss record 138 of 167
==15440==    at 0x4C20A69: malloc (vg_replace_malloc.c:149)
==15440==    by 0x74E9961: XCreateGC (in /usr/lib/libX11.so.6.2.0)
==15440==    by 0x568D288: _gdk_x11_gc_new (in /usr/lib/libgdk-x11-2.0.so.0.1000.11)
==15440==    by 0x51AC2AB: (within /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x7E33CCF: g_cache_insert (in /usr/lib/libglib-2.0.so.0.1200.11)
==15440==    by 0x51AC6F4: gtk_gc_get (in /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x525D03F: (within /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x77DD7D9: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1200.11)
==15440==    by 0x77ED84C: (within /usr/lib/libgobject-2.0.so.0.1200.11)
==15440==    by 0x77EE842: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.1200.11)
==15440==    by 0x77EEA12: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.1200.11)
==15440==    by 0x5255337: gtk_style_attach (in /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440== 
==15440== 
==15440== 4,956 bytes in 206 blocks are still reachable in loss record 139 of 167
==15440==    at 0x4C20A69: malloc (vg_replace_malloc.c:149)
==15440==    by 0x7512D55: (within /usr/lib/libX11.so.6.2.0)
==15440==    by 0x75139AA: (within /usr/lib/libX11.so.6.2.0)
==15440==    by 0x7513E07: XrmGetStringDatabase (in /usr/lib/libX11.so.6.2.0)
==15440==    by 0x74F069F: XGetDefault (in /usr/lib/libX11.so.6.2.0)
==15440==    by 0x6BFF0C3: _XcursorGetDisplayInfo (in /usr/lib/libXcursor.so.1.0.2)
==15440==    by 0x6BFF178: XcursorGetTheme (in /usr/lib/libXcursor.so.1.0.2)
==15440==    by 0x567DAC7: gdk_x11_display_set_cursor_theme (in /usr/lib/libgdk-x11-2.0.so.0.1000.11)
==15440==    by 0x524415C: (within /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x524468D: gtk_settings_get_for_screen (in /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x525C748: (within /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x77FCC5F: g_type_create_instance (in /usr/lib/libgobject-2.0.so.0.1200.11)
==15440== 
==15440== 
==15440== 5,088 bytes in 159 blocks are still reachable in loss record 140 of 167
==15440==    at 0x4C20A69: malloc (vg_replace_malloc.c:149)
==15440==    by 0x61B992D: (within /usr/lib/libfontconfig.so.1.2.0)
==15440==    by 0x61BA474: (within /usr/lib/libfontconfig.so.1.2.0)
==15440==    by 0x61BB824: (within /usr/lib/libfontconfig.so.1.2.0)
==15440==    by 0x90FE277: (within /usr/lib/libexpat.so.1.0.0)
==15440==    by 0x90FEF63: (within /usr/lib/libexpat.so.1.0.0)
==15440==    by 0x90FFFC8: (within /usr/lib/libexpat.so.1.0.0)
==15440==    by 0x910103A: (within /usr/lib/libexpat.so.1.0.0)
==15440==    by 0x90F8180: XML_ParseBuffer (in /usr/lib/libexpat.so.1.0.0)
==15440==    by 0x61BACB7: FcConfigParseAndLoad (in /usr/lib/libfontconfig.so.1.2.0)
==15440==    by 0x61BAF3F: FcConfigParseAndLoad (in /usr/lib/libfontconfig.so.1.2.0)
==15440==    by 0x61BB023: (within /usr/lib/libfontconfig.so.1.2.0)
==15440== 
==15440== 
==15440== 5,344 bytes in 167 blocks are still reachable in loss record 141 of 167
==15440==    at 0x4C20A69: malloc (vg_replace_malloc.c:149)
==15440==    by 0x61B9539: (within /usr/lib/libfontconfig.so.1.2.0)
==15440==    by 0x61BA194: (within /usr/lib/libfontconfig.so.1.2.0)
==15440==    by 0x61BB814: (within /usr/lib/libfontconfig.so.1.2.0)
==15440==    by 0x90FE277: (within /usr/lib/libexpat.so.1.0.0)
==15440==    by 0x90FEF63: (within /usr/lib/libexpat.so.1.0.0)
==15440==    by 0x90FFFC8: (within /usr/lib/libexpat.so.1.0.0)
==15440==    by 0x910103A: (within /usr/lib/libexpat.so.1.0.0)
==15440==    by 0x90F8180: XML_ParseBuffer (in /usr/lib/libexpat.so.1.0.0)
==15440==    by 0x61BACB7: FcConfigParseAndLoad (in /usr/lib/libfontconfig.so.1.2.0)
==15440==    by 0x61BAF3F: FcConfigParseAndLoad (in /usr/lib/libfontconfig.so.1.2.0)
==15440==    by 0x61BB023: (within /usr/lib/libfontconfig.so.1.2.0)
==15440== 
==15440== 
==15440== 5,421 bytes in 385 blocks are still reachable in loss record 142 of 167
==15440==    at 0x4C20A69: malloc (vg_replace_malloc.c:149)
==15440==    by 0x61B87D3: FcStrCopy (in /usr/lib/libfontconfig.so.1.2.0)
==15440==    by 0x61B8818: FcStrSetAdd (in /usr/lib/libfontconfig.so.1.2.0)
==15440==    by 0x61BAB9B: FcConfigParseAndLoad (in /usr/lib/libfontconfig.so.1.2.0)
==15440==    by 0x61BAF3F: FcConfigParseAndLoad (in /usr/lib/libfontconfig.so.1.2.0)
==15440==    by 0x61BB023: (within /usr/lib/libfontconfig.so.1.2.0)
==15440==    by 0x61BB45B: (within /usr/lib/libfontconfig.so.1.2.0)
==15440==    by 0x90FE277: (within /usr/lib/libexpat.so.1.0.0)
==15440==    by 0x90FEF63: (within /usr/lib/libexpat.so.1.0.0)
==15440==    by 0x90FFFC8: (within /usr/lib/libexpat.so.1.0.0)
==15440==    by 0x910103A: (within /usr/lib/libexpat.so.1.0.0)
==15440==    by 0x90F8180: XML_ParseBuffer (in /usr/lib/libexpat.so.1.0.0)
==15440== 
==15440== 
==15440== 6,792 bytes in 1 blocks are still reachable in loss record 143 of 167
==15440==    at 0x4C20A69: malloc (vg_replace_malloc.c:149)
==15440==    by 0x74FCF3E: XOpenDisplay (in /usr/lib/libX11.so.6.2.0)
==15440==    by 0x567EF18: gdk_display_open (in /usr/lib/libgdk-x11-2.0.so.0.1000.11)
==15440==    by 0x565E77C: gdk_display_open_default_libgtk_only (in /usr/lib/libgdk-x11-2.0.so.0.1000.11)
==15440==    by 0x51E64E3: gtk_init_check (in /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x51E6508: gtk_init (in /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x402827: main (in /home/mlallema/detection)
==15440== 
==15440== 
==15440== 7,080 bytes in 59 blocks are still reachable in loss record 144 of 167
==15440==    at 0x4C20A69: malloc (vg_replace_malloc.c:149)
==15440==    by 0x72677BC: (within /usr/lib/libcairo.so.2.11.1)
==15440==    by 0x7268486: cairo_scaled_font_glyph_extents (in /usr/lib/libcairo.so.2.11.1)
==15440==    by 0x5F99AA0: (within /usr/lib/libpangocairo-1.0.so.0.1600.2)
==15440==    by 0x8A438A9: pango_ot_buffer_output (in /usr/lib/libpangoft2-1.0.so.0.1600.2)
==15440==    by 0xB308B66: (within /usr/lib/pango/1.6.0/modules/pango-basic-fc.so)
==15440==    by 0x703121D: pango_shape (in /usr/lib/libpango-1.0.so.0.1600.2)
==15440==    by 0x702524B: (within /usr/lib/libpango-1.0.so.0.1600.2)
==15440==    by 0x7027A8D: (within /usr/lib/libpango-1.0.so.0.1600.2)
==15440==    by 0x7027FB4: (within /usr/lib/libpango-1.0.so.0.1600.2)
==15440==    by 0x702887C: (within /usr/lib/libpango-1.0.so.0.1600.2)
==15440==    by 0x51D8A52: (within /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440== 
==15440== 
==15440== 7,728 bytes in 46 blocks are still reachable in loss record 145 of 167
==15440==    at 0x4C20A69: malloc (vg_replace_malloc.c:149)
==15440==    by 0x72966D4: (within /usr/lib/libcairo.so.2.11.1)
==15440==    by 0x72969CA: (within /usr/lib/libcairo.so.2.11.1)
==15440==    by 0x7260F3D: cairo_image_surface_create_for_data (in /usr/lib/libcairo.so.2.11.1)
==15440==    by 0x72742F5: (within /usr/lib/libcairo.so.2.11.1)
==15440==    by 0x727695A: (within /usr/lib/libcairo.so.2.11.1)
==15440==    by 0x7267762: (within /usr/lib/libcairo.so.2.11.1)
==15440==    by 0x7289F36: (within /usr/lib/libcairo.so.2.11.1)
==15440==    by 0x726B0F6: (within /usr/lib/libcairo.so.2.11.1)
==15440==    by 0x725DDB7: (within /usr/lib/libcairo.so.2.11.1)
==15440==    by 0x72579D9: cairo_show_glyphs (in /usr/lib/libcairo.so.2.11.1)
==15440==    by 0x5F992F5: (within /usr/lib/libpangocairo-1.0.so.0.1600.2)
==15440== 
==15440== 
==15440== 8,424 bytes in 351 blocks are still reachable in loss record 146 of 167
==15440==    at 0x4C20A69: malloc (vg_replace_malloc.c:149)
==15440==    by 0x61B9AFA: (within /usr/lib/libfontconfig.so.1.2.0)
==15440==    by 0x61BB2C9: (within /usr/lib/libfontconfig.so.1.2.0)
==15440==    by 0x90FE277: (within /usr/lib/libexpat.so.1.0.0)
==15440==    by 0x90FEF63: (within /usr/lib/libexpat.so.1.0.0)
==15440==    by 0x90FFFC8: (within /usr/lib/libexpat.so.1.0.0)
==15440==    by 0x910103A: (within /usr/lib/libexpat.so.1.0.0)
==15440==    by 0x90F8180: XML_ParseBuffer (in /usr/lib/libexpat.so.1.0.0)
==15440==    by 0x61BACB7: FcConfigParseAndLoad (in /usr/lib/libfontconfig.so.1.2.0)
==15440==    by 0x61BAF3F: FcConfigParseAndLoad (in /usr/lib/libfontconfig.so.1.2.0)
==15440==    by 0x61BB023: (within /usr/lib/libfontconfig.so.1.2.0)
==15440==    by 0x61BB45B: (within /usr/lib/libfontconfig.so.1.2.0)
==15440== 
==15440== 
==15440== 8,544 bytes in 407 blocks are still reachable in loss record 147 of 167
==15440==    at 0x4C20A69: malloc (vg_replace_malloc.c:149)
==15440==    by 0x4C20AE3: realloc (vg_replace_malloc.c:306)
==15440==    by 0x7E507F0: g_realloc (in /usr/lib/libglib-2.0.so.0.1200.11)
==15440==    by 0x77F94FA: (within /usr/lib/libgobject-2.0.so.0.1200.11)
==15440==    by 0x77FD32F: g_type_register_static (in /usr/lib/libgobject-2.0.so.0.1200.11)
==15440==    by 0x77FD4C7: g_type_register_static_simple (in /usr/lib/libgobject-2.0.so.0.1200.11)
==15440==    by 0x512D89A: gtk_button_get_type (in /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x512E008: gtk_button_new_with_label (in /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x402F0A: main (in /home/mlallema/detection)
==15440== 
==15440== 
==15440== 9,743 bytes in 238 blocks are still reachable in loss record 148 of 167
==15440==    at 0x4C20A69: malloc (vg_replace_malloc.c:149)
==15440==    by 0x61B5C01: (within /usr/lib/libfontconfig.so.1.2.0)
==15440==    by 0x61B6AED: (within /usr/lib/libfontconfig.so.1.2.0)
==15440==    by 0x61B3A65: FcFontRenderPrepare (in /usr/lib/libfontconfig.so.1.2.0)
==15440==    by 0x8A40E6E: (within /usr/lib/libpangoft2-1.0.so.0.1600.2)
==15440==    by 0x702041C: (within /usr/lib/libpango-1.0.so.0.1600.2)
==15440==    by 0x702077C: pango_itemize_with_base_dir (in /usr/lib/libpango-1.0.so.0.1600.2)
==15440==    by 0x7027CD2: (within /usr/lib/libpango-1.0.so.0.1600.2)
==15440==    by 0x702887C: (within /usr/lib/libpango-1.0.so.0.1600.2)
==15440==    by 0x51D8A52: (within /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x511C52D: (within /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x77DD897: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1200.11)
==15440== 
==15440== 
==15440== 12,144 bytes in 46 blocks are still reachable in loss record 149 of 167
==15440==    at 0x4C20A69: malloc (vg_replace_malloc.c:149)
==15440==    by 0x7260DE2: (within /usr/lib/libcairo.so.2.11.1)
==15440==    by 0x72742F5: (within /usr/lib/libcairo.so.2.11.1)
==15440==    by 0x727695A: (within /usr/lib/libcairo.so.2.11.1)
==15440==    by 0x7267762: (within /usr/lib/libcairo.so.2.11.1)
==15440==    by 0x7289F36: (within /usr/lib/libcairo.so.2.11.1)
==15440==    by 0x726B0F6: (within /usr/lib/libcairo.so.2.11.1)
==15440==    by 0x725DDB7: (within /usr/lib/libcairo.so.2.11.1)
==15440==    by 0x72579D9: cairo_show_glyphs (in /usr/lib/libcairo.so.2.11.1)
==15440==    by 0x5F992F5: (within /usr/lib/libpangocairo-1.0.so.0.1600.2)
==15440==    by 0x702D4FD: pango_renderer_draw_glyphs (in /usr/lib/libpango-1.0.so.0.1600.2)
==15440==    by 0x5F988D7: (within /usr/lib/libpangocairo-1.0.so.0.1600.2)
==15440== 
==15440== 
==15440== 12,272 bytes in 59 blocks are still reachable in loss record 150 of 167
==15440==    at 0x4C20A69: malloc (vg_replace_malloc.c:149)
==15440==    by 0x750CAC5: _XEnq (in /usr/lib/libX11.so.6.2.0)
==15440==    by 0x750E2EF: _XReply (in /usr/lib/libX11.so.6.2.0)
==15440==    by 0x75085A9: XSync (in /usr/lib/libX11.so.6.2.0)
==15440==    by 0x569050F: _gdk_image_new_for_depth (in /usr/lib/libgdk-x11-2.0.so.0.1000.11)
==15440==    by 0x56661B7: (within /usr/lib/libgdk-x11-2.0.so.0.1000.11)
==15440==    by 0x56664B8: _gdk_image_get_scratch (in /usr/lib/libgdk-x11-2.0.so.0.1000.11)
==15440==    by 0x567154C: (within /usr/lib/libgdk-x11-2.0.so.0.1000.11)
==15440==    by 0x5671C08: gdk_draw_rgb_image_dithalign (in /usr/lib/libgdk-x11-2.0.so.0.1000.11)
==15440==    by 0x5662695: (within /usr/lib/libgdk-x11-2.0.so.0.1000.11)
==15440==    by 0x56869F2: (within /usr/lib/libgdk-x11-2.0.so.0.1000.11)
==15440==    by 0x407880: configPixmap (in /home/mlallema/detection)
==15440== 
==15440== 
==15440== 16,352 bytes in 2 blocks are still reachable in loss record 151 of 167
==15440==    at 0x4C20A69: malloc (vg_replace_malloc.c:149)
==15440==    by 0x75016B4: (within /usr/lib/libX11.so.6.2.0)
==15440==    by 0x7501A89: _XrmInternalStringToQuark (in /usr/lib/libX11.so.6.2.0)
==15440==    by 0x751E938: _XlcGetCharSet (in /usr/lib/libX11.so.6.2.0)
==15440==    by 0x751E58C: _XlcAddCT (in /usr/lib/libX11.so.6.2.0)
==15440==    by 0x751E81C: _XlcInitCTInfo (in /usr/lib/libX11.so.6.2.0)
==15440==    by 0x752481B: (within /usr/lib/libX11.so.6.2.0)
==15440==    by 0x7522A57: (within /usr/lib/libX11.so.6.2.0)
==15440==    by 0x75245D5: _XlcCreateLC (in /usr/lib/libX11.so.6.2.0)
==15440==    by 0x7543D9F: _XlcUtf8Loader (in /usr/lib/libX11.so.6.2.0)
==15440==    by 0x752AAD3: _XOpenLC (in /usr/lib/libX11.so.6.2.0)
==15440==    by 0x752ABC7: _XlcCurrentLC (in /usr/lib/libX11.so.6.2.0)
==15440== 
==15440== 
==15440== 16,384 bytes in 1 blocks are still reachable in loss record 152 of 167
==15440==    at 0x4C1FD92: calloc (vg_replace_malloc.c:279)
==15440==    by 0x74FC386: XOpenDisplay (in /usr/lib/libX11.so.6.2.0)
==15440==    by 0x567EF18: gdk_display_open (in /usr/lib/libgdk-x11-2.0.so.0.1000.11)
==15440==    by 0x565E77C: gdk_display_open_default_libgtk_only (in /usr/lib/libgdk-x11-2.0.so.0.1000.11)
==15440==    by 0x51E64E3: gtk_init_check (in /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x51E6508: gtk_init (in /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x402827: main (in /home/mlallema/detection)
==15440== 
==15440== 
==15440== 34,400 bytes in 1,075 blocks are indirectly lost in loss record 153 of 167
==15440==    at 0x4C20A69: malloc (vg_replace_malloc.c:149)
==15440==    by 0x61B69ED: (within /usr/lib/libfontconfig.so.1.2.0)
==15440==    by 0x61B3B63: FcFontRenderPrepare (in /usr/lib/libfontconfig.so.1.2.0)
==15440==    by 0x8A40E6E: (within /usr/lib/libpangoft2-1.0.so.0.1600.2)
==15440==    by 0x702041C: (within /usr/lib/libpango-1.0.so.0.1600.2)
==15440==    by 0x702077C: pango_itemize_with_base_dir (in /usr/lib/libpango-1.0.so.0.1600.2)
==15440==    by 0x7027CD2: (within /usr/lib/libpango-1.0.so.0.1600.2)
==15440==    by 0x702887C: (within /usr/lib/libpango-1.0.so.0.1600.2)
==15440==    by 0x51D8A52: (within /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x511C52D: (within /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x77DD897: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1200.11)
==15440==    by 0x77ED84C: (within /usr/lib/libgobject-2.0.so.0.1200.11)
==15440== 
==15440== 
==15440== 54,688 (19,200 direct, 35,488 indirect) bytes in 37 blocks are definitely lost in loss record 154 of 167
==15440==    at 0x4C20B6B: realloc (vg_replace_malloc.c:306)
==15440==    by 0x61B6153: (within /usr/lib/libfontconfig.so.1.2.0)
==15440==    by 0x61B6B2D: (within /usr/lib/libfontconfig.so.1.2.0)
==15440==    by 0x61B3A65: FcFontRenderPrepare (in /usr/lib/libfontconfig.so.1.2.0)
==15440==    by 0x8A40E6E: (within /usr/lib/libpangoft2-1.0.so.0.1600.2)
==15440==    by 0x702041C: (within /usr/lib/libpango-1.0.so.0.1600.2)
==15440==    by 0x702077C: pango_itemize_with_base_dir (in /usr/lib/libpango-1.0.so.0.1600.2)
==15440==    by 0x7027CD2: (within /usr/lib/libpango-1.0.so.0.1600.2)
==15440==    by 0x702887C: (within /usr/lib/libpango-1.0.so.0.1600.2)
==15440==    by 0x51D8A52: (within /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x511C52D: (within /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x77DD897: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1200.11)
==15440== 
==15440== 
==15440== 22,528 bytes in 1 blocks are still reachable in loss record 155 of 167
==15440==    at 0x4C20A69: malloc (vg_replace_malloc.c:149)
==15440==    by 0x750BE3F: _XAllocScratch (in /usr/lib/libX11.so.6.2.0)
==15440==    by 0x7500E9B: (within /usr/lib/libX11.so.6.2.0)
==15440==    by 0x750125A: XPutImage (in /usr/lib/libX11.so.6.2.0)
==15440==    by 0x56873C9: (within /usr/lib/libgdk-x11-2.0.so.0.1000.11)
==15440==    by 0x56715E8: (within /usr/lib/libgdk-x11-2.0.so.0.1000.11)
==15440==    by 0x5671C08: gdk_draw_rgb_image_dithalign (in /usr/lib/libgdk-x11-2.0.so.0.1000.11)
==15440==    by 0x5662695: (within /usr/lib/libgdk-x11-2.0.so.0.1000.11)
==15440==    by 0x56869F2: (within /usr/lib/libgdk-x11-2.0.so.0.1000.11)
==15440==    by 0x407880: configPixmap (in /home/mlallema/detection)
==15440==    by 0x406139: configure_event (in /home/mlallema/detection)
==15440==    by 0x51EB68C: _gtk_marshal_BOOLEAN__BOXED (in /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440== 
==15440== 
==15440== 101,249 bytes in 106 blocks are still reachable in loss record 156 of 167
==15440==    at 0x4C20A69: malloc (vg_replace_malloc.c:149)
==15440==    by 0x8C7181F: ft_mem_qalloc (in /usr/lib/libfreetype.so.6.3.10)
==15440==    by 0x8C76E62: ft_mem_alloc (in /usr/lib/libfreetype.so.6.3.10)
==15440==    by 0x8C859EA: TT_New_Context (in /usr/lib/libfreetype.so.6.3.10)
==15440==    by 0x8C85AC8: (within /usr/lib/libfreetype.so.6.3.10)
==15440==    by 0x8C77692: FT_Add_Module (in /usr/lib/libfreetype.so.6.3.10)
==15440==    by 0x8C7177E: FT_Add_Default_Modules (in /usr/lib/libfreetype.so.6.3.10)
==15440==    by 0x8C71807: FT_Init_FreeType (in /usr/lib/libfreetype.so.6.3.10)
==15440==    by 0x5F9A034: (within /usr/lib/libpangocairo-1.0.so.0.1600.2)
==15440==    by 0x77FCC5F: g_type_create_instance (in /usr/lib/libgobject-2.0.so.0.1200.11)
==15440==    by 0x77E402C: (within /usr/lib/libgobject-2.0.so.0.1200.11)
==15440==    by 0x77E2483: g_object_newv (in /usr/lib/libgobject-2.0.so.0.1200.11)
==15440== 
==15440== 
==15440== 105,184 bytes in 50 blocks are possibly lost in loss record 157 of 167
==15440==    at 0x4C1FC7D: memalign (vg_replace_malloc.c:332)
==15440==    by 0x4C1FCD6: posix_memalign (vg_replace_malloc.c:421)
==15440==    by 0x7E5EB60: (within /usr/lib/libglib-2.0.so.0.1200.11)
==15440==    by 0x7E5FE7B: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1200.11)
==15440==    by 0x7E5FF95: g_slice_alloc0 (in /usr/lib/libglib-2.0.so.0.1200.11)
==15440==    by 0x77FC79E: g_type_create_instance (in /usr/lib/libgobject-2.0.so.0.1200.11)
==15440==    by 0x77E402C: (within /usr/lib/libgobject-2.0.so.0.1200.11)
==15440==    by 0x77E2483: g_object_newv (in /usr/lib/libgobject-2.0.so.0.1200.11)
==15440==    by 0x77E2EAB: g_object_new_valist (in /usr/lib/libgobject-2.0.so.0.1200.11)
==15440==    by 0x77E30E0: g_object_new (in /usr/lib/libgobject-2.0.so.0.1200.11)
==15440==    by 0x51D5E21: gtk_label_new (in /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x512E2E1: (within /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440== 
==15440== 
==15440== 121,546 bytes in 1,038 blocks are still reachable in loss record 158 of 167
==15440==    at 0x4C1FD92: calloc (vg_replace_malloc.c:279)
==15440==    by 0x7E50891: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1200.11)
==15440==    by 0x77FBEA0: g_type_class_ref (in /usr/lib/libgobject-2.0.so.0.1200.11)
==15440==    by 0x77E2CE0: g_object_new_valist (in /usr/lib/libgobject-2.0.so.0.1200.11)
==15440==    by 0x77E30E0: g_object_new (in /usr/lib/libgobject-2.0.so.0.1200.11)
==15440==    by 0x512259E: gtk_adjustment_new (in /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x521A8C4: gtk_progress_set_adjustment (in /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x521AB2C: gtk_progress_get_current_percentage (in /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x521CFF2: (within /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x521B4AE: (within /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x77DD7D9: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1200.11)
==15440==    by 0x77ED84C: (within /usr/lib/libgobject-2.0.so.0.1200.11)
==15440== 
==15440== 
==15440== 230,272 bytes in 2,875 blocks are still reachable in loss record 159 of 167
==15440==    at 0x4C20B6B: realloc (vg_replace_malloc.c:306)
==15440==    by 0x7E507F0: g_realloc (in /usr/lib/libglib-2.0.so.0.1200.11)
==15440==    by 0x7E2CDD9: (within /usr/lib/libglib-2.0.so.0.1200.11)
==15440==    by 0x7E2D2E9: g_array_insert_vals (in /usr/lib/libglib-2.0.so.0.1200.11)
==15440==    by 0x522811A: (within /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x5228321: (within /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0xA5FC106: (within /usr/lib/gtk-2.0/2.10.0/engines/libubuntulooks.so)
==15440==    by 0x52296F0: (within /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x5229C15: gtk_rc_get_style (in /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x52EE467: (within /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x52474C4: (within /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x524771E: _gtk_size_group_compute_requisition (in /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440== 
==15440== 
==15440== 261,517 bytes in 6,908 blocks are still reachable in loss record 160 of 167
==15440==    at 0x4C20A69: malloc (vg_replace_malloc.c:149)
==15440==    by 0x7E5090A: g_malloc (in /usr/lib/libglib-2.0.so.0.1200.11)
==15440==    by 0x7E627FE: g_strdup (in /usr/lib/libglib-2.0.so.0.1200.11)
==15440==    by 0x7E6E7A9: g_set_prgname (in /usr/lib/libglib-2.0.so.0.1200.11)
==15440==    by 0x7E56502: g_option_context_parse (in /usr/lib/libglib-2.0.so.0.1200.11)
==15440==    by 0x51E647E: gtk_parse_args (in /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x51E64D8: gtk_init_check (in /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x51E6508: gtk_init (in /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x402827: main (in /home/mlallema/detection)
==15440== 
==15440== 
==15440== 369,024 bytes in 664 blocks are still reachable in loss record 161 of 167
==15440==    at 0x4C1FC7D: memalign (vg_replace_malloc.c:332)
==15440==    by 0x4C1FCD6: posix_memalign (vg_replace_malloc.c:421)
==15440==    by 0x7E5EB60: (within /usr/lib/libglib-2.0.so.0.1200.11)
==15440==    by 0x7E5FE7B: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1200.11)
==15440==    by 0x7E60662: g_slist_append (in /usr/lib/libglib-2.0.so.0.1200.11)
==15440==    by 0x5227D92: (within /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x5229BB5: gtk_rc_get_style (in /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x52EE467: (within /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x52474C4: (within /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x524771E: _gtk_size_group_compute_requisition (in /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x51AB317: (within /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x77DD897: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1200.11)
==15440== 
==15440== 
==15440== 4,882,368 bytes in 76,287 blocks are indirectly lost in loss record 162 of 167
==15440==    at 0x4C20A69: malloc (vg_replace_malloc.c:149)
==15440==    by 0x40434F: calculHistoRGB (in /home/mlallema/detection)
==15440==    by 0x40806D: kppvManhattan (in /home/mlallema/detection)
==15440==    by 0x406FF7: reconnaissancePortraitManhattan (in /home/mlallema/detection)
==15440==    by 0x77DD7D9: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1200.11)
==15440==    by 0x77ED407: (within /usr/lib/libgobject-2.0.so.0.1200.11)
==15440==    by 0x77EE842: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.1200.11)
==15440==    by 0x77EEA12: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.1200.11)
==15440==    by 0x512F688: (within /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x77DD7D9: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1200.11)
==15440==    by 0x77ED84C: (within /usr/lib/libgobject-2.0.so.0.1200.11)
==15440==    by 0x77EE842: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.1200.11)
==15440== 
==15440== 
==15440== 5,492,672 (610,304 direct, 4,882,368 indirect) bytes in 4,768 blocks are definitely lost in loss record 163 of 167
==15440==    at 0x4C20A69: malloc (vg_replace_malloc.c:149)
==15440==    by 0x404313: calculHistoRGB (in /home/mlallema/detection)
==15440==    by 0x40806D: kppvManhattan (in /home/mlallema/detection)
==15440==    by 0x406FF7: reconnaissancePortraitManhattan (in /home/mlallema/detection)
==15440==    by 0x77DD7D9: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1200.11)
==15440==    by 0x77ED407: (within /usr/lib/libgobject-2.0.so.0.1200.11)
==15440==    by 0x77EE842: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.1200.11)
==15440==    by 0x77EEA12: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.1200.11)
==15440==    by 0x512F688: (within /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x77DD7D9: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1200.11)
==15440==    by 0x77ED84C: (within /usr/lib/libgobject-2.0.so.0.1200.11)
==15440==    by 0x77EE842: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.1200.11)
==15440== 
==15440== 
==15440== 786,432 bytes in 12 blocks are still reachable in loss record 164 of 167
==15440==    at 0x4C20A69: malloc (vg_replace_malloc.c:149)
==15440==    by 0x56903FA: _gdk_image_new_for_depth (in /usr/lib/libgdk-x11-2.0.so.0.1000.11)
==15440==    by 0x56661B7: (within /usr/lib/libgdk-x11-2.0.so.0.1000.11)
==15440==    by 0x56664DD: _gdk_image_get_scratch (in /usr/lib/libgdk-x11-2.0.so.0.1000.11)
==15440==    by 0x567154C: (within /usr/lib/libgdk-x11-2.0.so.0.1000.11)
==15440==    by 0x5671C08: gdk_draw_rgb_image_dithalign (in /usr/lib/libgdk-x11-2.0.so.0.1000.11)
==15440==    by 0x5662695: (within /usr/lib/libgdk-x11-2.0.so.0.1000.11)
==15440==    by 0x56869F2: (within /usr/lib/libgdk-x11-2.0.so.0.1000.11)
==15440==    by 0x407880: configPixmap (in /home/mlallema/detection)
==15440==    by 0x406139: configure_event (in /home/mlallema/detection)
==15440==    by 0x51EB68C: _gtk_marshal_BOOLEAN__BOXED (in /usr/lib/libgtk-x11-2.0.so.0.1000.11)
==15440==    by 0x77DD7D9: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1200.11)
==15440== 
==15440== 
==15440== 817,074 bytes in 2,086 blocks are still reachable in loss record 165 of 167
==15440==    at 0x4C20A69: malloc (vg_replace_malloc.c:149)
==15440==    by 0x8A45401: (within /usr/lib/libpangoft2-1.0.so.0.1600.2)
==15440==    by 0x8A52450: (within /usr/lib/libpangoft2-1.0.so.0.1600.2)
==15440==    by 0x8A5D936: (within /usr/lib/libpangoft2-1.0.so.0.1600.2)
==15440==    by 0x8A53D7F: (within /usr/lib/libpangoft2-1.0.so.0.1600.2)
==15440==    by 0x8A4413D: pango_ot_info_get_gpos (in /usr/lib/libpangoft2-1.0.so.0.1600.2)
==15440==    by 0x8A44296: (within /usr/lib/libpangoft2-1.0.so.0.1600.2)
==15440==    by 0x8A44A40: pango_ot_info_find_script (in /usr/lib/libpangoft2-1.0.so.0.1600.2)
==15440==    by 0xB308BE2: (within /usr/lib/pango/1.6.0/modules/pango-basic-fc.so)
==15440==    by 0x703121D: pango_shape (in /usr/lib/libpango-1.0.so.0.1600.2)
==15440==    by 0x702524B: (within /usr/lib/libpango-1.0.so.0.1600.2)
==15440==    by 0x7027A8D: (within /usr/lib/libpango-1.0.so.0.1600.2)
==15440== 
==15440== 
==15440== 877,200 bytes in 3 blocks are still reachable in loss record 166 of 167
==15440==    at 0x4C20A69: malloc (vg_replace_malloc.c:149)
==15440==    by 0x5AFDEA4: gdk_pixbuf_new (in /usr/lib/libgdk_pixbuf-2.0.so.0.1000.11)
==15440==    by 0xA8299BF: (within /usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-jpeg.so)
==15440==    by 0x5B013A2: _gdk_pixbuf_generic_image_load (in /usr/lib/libgdk_pixbuf-2.0.so.0.1000.11)
==15440==    by 0x5B025A9: gdk_pixbuf_new_from_file (in /usr/lib/libgdk_pixbuf-2.0.so.0.1000.11)
==15440==    by 0x402AA7: main (in /home/mlallema/detection)
==15440== 
==15440== 
==15440== 3,239,904 bytes in 6 blocks are still reachable in loss record 167 of 167
==15440==    at 0x4C20A69: malloc (vg_replace_malloc.c:149)
==15440==    by 0x5AFDFBC: gdk_pixbuf_copy (in /usr/lib/libgdk_pixbuf-2.0.so.0.1000.11)
==15440==    by 0x402AE7: main (in /home/mlallema/detection)
==15440== 
==15440== LEAK SUMMARY:
==15440==    definitely lost: 630,426 bytes in 4,830 blocks.
==15440==    indirectly lost: 4,918,192 bytes in 77,409 blocks.
==15440==      possibly lost: 106,784 bytes in 70 blocks.
==15440==    still reachable: 7,037,182 bytes in 17,504 blocks.
==15440==         suppressed: 0 bytes in 0 blocks.

Alors, déjà ce qu'il faut savoir, c'est qu'il faut ignorer tous les "still reachable", au moins en première approche, donc par exemple le premier on s'en fout. C'est de la mémoire non libérée, mais sur laquelle existe un pointeur, donc tu aurais pu la libérer si tu avais voulu.
Ce qui nous intéresse, c'est les "definitely lost", quand tu regardes les stats tout à la fin, valgrind en a trouvé :
Code:

1 2 3 4 5 6 7 ==15440== LEAK SUMMARY: ==15440== definitely lost: 630,426 bytes in 4,830 blocks. ==15440== indirectly lost: 4,918,192 bytes in 77,409 blocks. ==15440== possibly lost: 106,784 bytes in 70 blocks. ==15440== still reachable: 7,037,182 bytes in 17,504 blocks. ==15440== suppressed: 0 bytes in 0 blocks.
Et effectivement, en regardant les traces, y a :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ==15440== 5,492,672 (610,304 direct, 4,882,368 indirect) bytes in 4,768 blocks are definitely lost in loss record 163 of 167 ==15440== at 0x4C20A69: malloc (vg_replace_malloc.c:149) ==15440== by 0x404313: calculHistoRGB (in /home/mlallema/detection) ==15440== by 0x40806D: kppvManhattan (in /home/mlallema/detection) ==15440== by 0x406FF7: reconnaissancePortraitManhattan (in /home/mlallema/detection) ==15440== by 0x77DD7D9: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1200.11) ==15440== by 0x77ED407: (within /usr/lib/libgobject-2.0.so.0.1200.11) ==15440== by 0x77EE842: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.1200.11) ==15440== by 0x77EEA12: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.1200.11) ==15440== by 0x512F688: (within /usr/lib/libgtk-x11-2.0.so.0.1000.11) ==15440== by 0x77DD7D9: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1200.11) ==15440== by 0x77ED84C: (within /usr/lib/libgobject-2.0.so.0.1200.11) ==15440== by 0x77EE842: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.1200.11) ==15440==
qui t'indique que y a eu un malloc sur lequel t'as pas fait de free dans calculHistoRGB. Si tu compiles ton programme avec des infos de debug (-g3 -ggdb3), t'auras même le n° de la ligne à laquelle le malloc a été fait.

Il vaut mieux avoir la variable G_SLICE à la valeur always-malloc dans ton environnement aussi quand tu utilises valgrind avec gtk+.