Discussion :

[LittleWhite]

Bonjour,

Je viens de me mettre à la glib, juste pour avoir des structures de données en C.
Vive les tables de hachage et autres \o/.

Donc aujourd'hui, j'utilise des GArray. Dans mes tableaux je veux des char*.
Avant d'ajouter mon char* avec 'g_array_append_val()', j'alloue la mémoire, et je copie la chaine à partir d'une source statique dans le nouvel endroit de mémoire. Je ne pense pas que la glib puisse copier ma chaines de caractères toute seule .
Bref ... j'ai un jolie char* ... qui un beau jour devra être désalloué.

Je pensais faire un bête:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
g_array_free(pVFile->pFile,TRUE);

Et comme j'avais mis à TRUE, je pensais que cela ferait des free() sur les éléments, mais il ne semble pas que ce soit le cas ( vive valgrind ).
Avant de faire ce g_array_free, je parcours donc mon tableau, pour faire les free de mes éléments.
Cela ne plante pas ... cela semble marcher ... mais tout les pointeurs sont déclaré par valgrind comme still reachable... du coup je pense toujours avoir une fuite de mémoire.

Quelqu'un peut t'il m'expliquer un peu le fonctionnement, et comment faire pour faire une libération de la mémoire propre?

Merci beaucoup

[liberforce]

Bonjour,

attention à la terminologie :
pointeur sur char → char *
pointeur sur char * → char **

Comme tu n'es pas trop précis sur les termes, c'est difficile de comprendre ce que tu essaies de faire. Nous montrer du code serait mieux. Mais si ce que tu veux faire, c'est avoir un tableau de pointeurs, où chaque élément pointe vers une chaîne de caractères déjà allouée, alors c'est vers GPtrArray qu'il faut t'orienter. Et si c'est un tableau où chaque élément est un caractère, alors utilise GByteArray...

[LittleWhite]

:red:

Je parle d'un tableau qui stockerai des char* ( des chaines de caractères ).
Je vais voir un peu plus tard sur les GPtrArray...

( Je corrige aussi mon post initial )

[teuf13]

Je seconde Liberforce, un exemple de code qui leake serait beaucoup plus précis. C'est les détails qui comptent, ce que tu décris est cohérent, mais il y a l'air d'avoir un problème dans ce que tu fais, problème que tu ne décriras pas avec des mots vu que tu n'as pas conscience de ce que c'est (sinon le problème n'existerait pas)

[LittleWhite]

Oui je comprends votre point de vue . C'est juste que je vais extraire les bouts de code important dans cas, et j'ai un peu peur de louper un truc à vous montrer.

Donc ... mon fichier .h:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
#include <glib.h>
 
typedef struct VFile
{
	GArray* pFile;
}VFile;
 
void cstVFile(VFile* const pVFile);
void dstVFile(VFile* const pVFile);

La définition des fonctions:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
 
void cstVFile(VFile* const pVFile)
{
	assert(pVFile);
 
	pVFile->pFile = g_array_sized_new(FALSE, FALSE, sizeof(char*), NB_LINES_FILE);
}
 
void dstVFile(VFile* const pVFile)
{
	unsigned int i = 0;
 
	assert(pVFile);
 
	for ( i = 0 ; i < pVFile->pFile->len ; i++ )
	{
		free(g_array_index(pVFile->pFile,char*,i));
	}
 
	g_array_free(pVFile->pFile,TRUE);
 
#ifdef _SAFE
	pVFile->pFile = NULL;
#endif
}

Et la partie de l'ajout dans le GArray:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
char* ligne = (char*) malloc(sizeof(char)*nbCar);
 
if ( ligne == NULL )
{
	fprintf(stderr, "Erreur d'allocation de mémoire pour la ligne");
	return -3;
}
 
strncpy(ligne, bufferLigne, nbCar);
ligne[nbCar-1]='\0';
 
// Ajout de la ligne dans le VFile
g_array_append_val(pVFile->pFile,ligne);

Dans le main:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
VFile vfileFR;
 
cstVFile(&vfileFR);
 
// Appel de la fonction ci dessus ...
 
dstVFile(&vfileFR);

Note: Je vais bientot remplacer ce GArray par un GPtrArray qui est une peu plus logique.

[teuf13]

Utilise g_strdup plutôt que malloc+strncpy, ça éliminera une possibilité d'erreur. Par contre la doc de g_array_free est explicite sur le fait que c'est à toi de libérer les éléments contenus dans le tableau un à un. Ce que fait g_array_free, c'est la libération de la structure GArray, et potentiellement de la mémoire allouée pour le tableau proprement dit (ie pour stocker les char*).

[LittleWhite]

J'ai fait le changement en g_strdup ...

Voici le log valgrind:

==16662== Memcheck, a memory error detector.
==16662== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==16662== Using LibVEX rev 1804, a library for dynamic binary translation.
==16662== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==16662== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation framework.
==16662== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==16662==
--16662-- Command line
--16662-- ./generateur
--16662-- Startup, with flags:
--16662-- --leak-check=full
--16662-- --show-reachable=yes
--16662-- -v
--16662-- Contents of /proc/version:
--16662-- Linux version 2.6.24-23-generic (buildd@palmer) (gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)) #1 SMP Wed Apr 1 21:47:28 UTC 2009
--16662-- Arch and hwcaps: X86, x86-sse1-sse2
--16662-- Page sizes: currently 4096, max supported 4096
--16662-- Valgrind library directory: /usr/lib/valgrind
--16662-- Reading syms from /lib/ld-2.7.so (0x4000000)
--16662-- Reading debug info from /lib/ld-2.7.so...
--16662-- ... CRC mismatch (computed 7fa7f4cc wanted 070f79e4)
--16662-- object doesn't have a symbol table
--16662-- Reading syms from /home/alexandre/algorithmique/Essai/Cyrine_P2/Seq_GLib/generateur (0x8048000)
--16662-- Reading syms from /usr/lib/valgrind/x86-linux/memcheck (0x38000000)
--16662-- object doesn't have a dynamic symbol table
--16662-- Reading suppressions file: /usr/lib/valgrind/default.supp
--16662-- Reading syms from /usr/lib/valgrind/x86-linux/vgpreload_core.so (0x401E000)
--16662-- Reading syms from /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so (0x4020000)
--16662-- Reading syms from /usr/lib/libglib-2.0.so.0.1600.6 (0x403E000)
--16662-- Reading debug info from /usr/lib/libglib-2.0.so.0.1600.6...
--16662-- ... CRC mismatch (computed e528f287 wanted 959774d1)
--16662-- object doesn't have a symbol table
--16662-- Reading syms from /lib/tls/i686/cmov/libm-2.7.so (0x40EF000)
--16662-- Reading debug info from /lib/tls/i686/cmov/libm-2.7.so...
--16662-- ... CRC mismatch (computed a35b3de9 wanted 4dd52e16)
--16662-- object doesn't have a symbol table
--16662-- Reading syms from /lib/tls/i686/cmov/libc-2.7.so (0x4115000)
--16662-- Reading debug info from /lib/tls/i686/cmov/libc-2.7.so...
--16662-- ... CRC mismatch (computed a60c1faf wanted 4edc7d98)
--16662-- object doesn't have a symbol table
--16662-- Reading syms from /usr/lib/libpcre.so.3.12.1 (0x4264000)
--16662-- Reading debug info from /usr/lib/libpcre.so.3.12.1...
--16662-- ... CRC mismatch (computed 730fa5c2 wanted e5be5499)
--16662-- object doesn't have a symbol table
--16662-- REDIR: 0x41876c0 (rindex) redirected to 0x4023710 (rindex)
=== Generateur (Glib version) - 13 Juin 2010 ===
--16662-- REDIR: 0x41872f0 (strlen) redirected to 0x40239d0 (strlen)
--16662-- REDIR: 0x41829d0 (calloc) redirected to 0x4021b70 (calloc)
--16662-- REDIR: 0x4183000 (posix_memalign) redirected to 0x4021b10 (posix_memalign)
--16662-- REDIR: 0x41846f0 (realloc) redirected to 0x4022b10 (realloc)
--16662-- REDIR: 0x4188550 (memset) redirected to 0x4023d50 (memset)
--16662-- REDIR: 0x4182cc0 (malloc) redirected to 0x4022a50 (malloc)
--16662-- REDIR: 0x4188050 (memchr) redirected to 0x4023bf0 (memchr)
--16662-- REDIR: 0x4188a40 (memcpy) redirected to 0x4024aa0 (memcpy)
--16662-- REDIR: 0x4184500 (free) redirected to 0x40225f0 (free)
--16662-- REDIR: 0x4189440 (strchrnul) redirected to 0x4023df0 (strchrnul)
Corpus FR lu -> 20
Corpus EN lu -> 20
--16662-- REDIR: 0x41875f0 (strncpy) redirected to 0x4024bf0 (strncpy)
--16662-- REDIR: 0x4186dc0 (strcmp) redirected to 0x4023aa0 (strcmp)
--16662-- REDIR: 0x41885b0 (mempcpy) redirected to 0x4024490 (mempcpy)
Creation tables de hachage - 20 lignes d'analysées
Table de hachages crées
--16662-- REDIR: 0x41884e0 (memmove) redirected to 0x4023da0 (memmove)
Elimination des doublons effectuée
Liste de séquences à calculer créee
Tri des séquences effectué
Calcul 402 / 402
IM calculées
==16662==
==16662== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
--16662--
--16662-- supp: 17 dl-hack3-1
==16662== malloc/free: in use at exit: 58,404 bytes in 221 blocks.
==16662== malloc/free: 2,256 allocs, 2,035 frees, 8,484,101 bytes allocated.
==16662==
==16662== searching for pointers to 221 not-freed blocks.
==16662== checked 124,624 bytes.
==16662==
==16662== 3,564 bytes in 4 blocks are still reachable in loss record 1 of 3
==16662== at 0x4021BDE: calloc (vg_replace_malloc.c:397)
==16662== by 0x407DC74: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1600.6)
==16662== by 0x40926DC: (within /usr/lib/libglib-2.0.so.0.1600.6)
==16662== by 0x4092F7A: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1600.6)
==16662== by 0x40504FE: g_array_sized_new (in /usr/lib/libglib-2.0.so.0.1600.6)
==16662== by 0x804CA93: cstVFile (vfile.c:15)
==16662== by 0x8049C5D: main (main.c:417)
==16662==
==16662==
==16662== 13,888 bytes in 56 blocks are possibly lost in loss record 2 of 3
==16662== at 0x4021A92: memalign (vg_replace_malloc.c:460)
==16662== by 0x4021B3F: posix_memalign (vg_replace_malloc.c:569)
==16662== by 0x40923A3: (within /usr/lib/libglib-2.0.so.0.1600.6)
==16662== by 0x40935D0: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1600.6)
==16662== by 0x40504FE: g_array_sized_new (in /usr/lib/libglib-2.0.so.0.1600.6)
==16662== by 0x804CA93: cstVFile (vfile.c:15)
==16662== by 0x8049C5D: main (main.c:417)
==16662==
==16662==
==16662== 40,952 bytes in 161 blocks are still reachable in loss record 3 of 3
==16662== at 0x4021A92: memalign (vg_replace_malloc.c:460)
==16662== by 0x4021B3F: posix_memalign (vg_replace_malloc.c:569)
==16662== by 0x40923A3: (within /usr/lib/libglib-2.0.so.0.1600.6)
==16662== by 0x409359B: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1600.6)
==16662== by 0x40504FE: g_array_sized_new (in /usr/lib/libglib-2.0.so.0.1600.6)
==16662== by 0x804CA93: cstVFile (vfile.c:15)
==16662== by 0x8049C5D: main (main.c:417)
==16662==
==16662== LEAK SUMMARY:
==16662== definitely lost: 0 bytes in 0 blocks.
==16662== possibly lost: 13,888 bytes in 56 blocks.
==16662== still reachable: 44,516 bytes in 165 blocks.
==16662== suppressed: 0 bytes in 0 blocks.
--16662-- memcheck: sanity checks: 280 cheap, 11 expensive
--16662-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use
--16662-- memcheck: auxmaps_L1: 0 searches, 0 cmps, ratio 0:10
--16662-- memcheck: auxmaps_L2: 0 searches, 0 nodes
--16662-- memcheck: SMs: n_issued = 17 (272k, 0M)
--16662-- memcheck: SMs: n_deissued = 0 (0k, 0M)
--16662-- memcheck: SMs: max_noaccess = 65535 (1048560k, 1023M)
--16662-- memcheck: SMs: max_undefined = 126 (2016k, 1M)
--16662-- memcheck: SMs: max_defined = 34 (544k, 0M)
--16662-- memcheck: SMs: max_non_DSM = 17 (272k, 0M)
--16662-- memcheck: max sec V bit nodes: 971 (49k, 0M)
--16662-- memcheck: set_sec_vbits8 calls: 971 (new: 971, updates: 0)
--16662-- memcheck: max shadow mem size: 625k, 0M
--16662-- translate: fast SP updates identified: 3,420 ( 88.8%)
--16662-- translate: generic_known SP updates identified: 238 ( 6.1%)
--16662-- translate: generic_unknown SP updates identified: 190 ( 4.9%)
--16662-- tt/tc: 35,821 tt lookups requiring 48,547 probes
--16662-- tt/tc: 35,821 fast-cache updates, 2 flushes
--16662-- transtab: new 3,261 (71,647 -> 1,028,899; ratio 143:10) [0 scs]
--16662-- transtab: dumped 0 (0 -> ??)
--16662-- transtab: discarded 0 (0 -> ??)
--16662-- scheduler: 28,092,135 jumps (bb entries).
--16662-- scheduler: 280/37,338 major/minor sched events.
--16662-- sanity: 281 cheap, 11 expensive checks.
--16662-- exectx: 769 lists, 75 contexts (avg 0 per list)
--16662-- exectx: 4,308 searches, 4,234 full compares (982 per 1000)
--16662-- exectx: 219 cmp2, 38 cmp4, 0 cmpAll
--16662-- errormgr: 9 supplist searches, 285 comparisons during search
--16662-- errormgr: 17 errlist searches, 38 comparisons during search

[teuf13]

il faut avoir G_SLICE=always-malloc dans ton environnement quand tu fais du valgrind avec la glib. Il y a 0 byte en definitely lost, donc ça ne me paraît pas très inquiétant ce que signale valgrind.

[LittleWhite]

il faut avoir G_SLICE=always-malloc dans ton environnement quand tu fais du valgrind avec la glib. Il y a 0 byte en definitely lost, donc ça ne me paraît pas très inquiétant ce que signale valgrind.

Très très très bon point.
Maintenant valgrind indique:

==27814== definitely lost: 0 bytes in 0 blocks.
==27814== possibly lost: 0 bytes in 0 blocks.
==27814== still reachable: 1,524 bytes in 3 blocks.
==27814== suppressed: 0 bytes in 0 blocks.

Je regarde pour le dernier petit problème.

Sachez que je ne m'en inquiétais pas de trop ... juste que je veux faire les choses proprement.

J'ai enfin mis les GPtrArray, qui sont légèrement plus simple à utiliser dans ce cas . Bien sur, cela n'a engendré aucun changement sur la mémoire ( enfin le rapport de valgrind ).

[liberforce]

Je rajouterai que pour utiliser Valgrind avec des programmes GTK ou GNOME, il y a pas mal d'autre options utiles : voir Valgrind sur le wiki GNOME. Par exemple, G_SLICE=always-malloc, évoqué plus haut, mais aussi G_DEBUG=gc-friendly.

[teuf13]

Les definitely lost sont inquiétants quand il y en a , les still reachable peuvent être uniquement là à titre informatif, des fois ce n'est pas grave d'avoir de la mémoire allouée jusqu'à la fin de ton programme.

[LittleWhite]

Merci liberforce et teuf13 pour votre aide