Discussion :

[nicaud77]

Bonjour à tous!

J'espère que vous allez pouvoir m'aider : Je m'explique.

J'utilise la Glib pour la manipulation de chaine de caractères.

voici le code tout bete :

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
 
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <string.h>
#include <unistd.h>
#include <glib.h>
 
 
int main(int argc, char *argv[])
{
 
printf("glib version : %d.%d.%d\n",
GLIB_MAJOR_VERSION,
GLIB_MINOR_VERSION,
GLIB_MICRO_VERSION);
 
GString *para1;
para1 = g_string_new("papa");
printf("\npara1->str : %s\n", para1->str);
 
g_string_free(para1, TRUE);
 
return 0;
}

Le probleme est que si je lance valgrind -v ./test
il me dit que :

malloc/free: 9 allocs, 1 frees, 4,564 bytes allocated.

Comment vraiment tout liberer?

Merci pour votre aide.

Le truc c'est que dans un programme un peu plus long, j'utilise pas mal de G_string et mon prog aléatoirement fait un SIGSEGV. le fichier core généré est peu explicite mais il y aurait bien un souci de fuite de memoire, d'ou mon interrogation sur ces bytes non desalloués. (la version GLib est la dernière)

MERCI

[Franck.H]

Salut !


Bin en fait c'est la GLib qui gère ca en interne, à moins de tenter un g_free sur le membre str de ton GString (normalement on a pas à y toucher mais il est accessible).

Sinon te pencher sur d'autres libs de gestion de chaînes de caractères, sauf si tu utilises GLib pour encore d'autres choses que les strings... Y'a ma petite bibliothèque (en signature) que tu peux tester le cas contraire

[nicaud77]

Merci mais j'utilise la bibliothèque GMBUS, qui utilise la GLIB...
Je continue donc mes investigations...

[nicolas.sitbon]

C'est un comportement tout ce qu'il y a de plus normal, si tu veux vraiment éviter les warnings avec valgrind, tu n'as pas de choix autre que de recompiler ta glib avec l'option --enable-gc-friendly.
Cordialement.

[nicaud77]

c'est de nouveau moi, le probleme c'est que j'ai toujours mes SIGSEGV.

nicolas.sitbon, ce n'est pas un warning dans valgrind, il y a bien des choses qui ne sont pas desallouées.

Je ne comprend pas le g_string_free(xxx, FALSE) : on le libere le g_string mais il est toujours disponible (xxx->str vaut bien quelque chose)?

En fait je ne vois pas trop à quoi ca peut servir avec le booleen FALSE dans la fonction g_string_free...

Merci pour vos futures réponses.

S'il y a des personnes ayant une connaissances en GMBus je suis preneur d'informations. Merci

[senteur_jasmin]

Bonjour,

A priori, aucun probleme en ce qui concerne l'alloc / free de la structure GString, comme te l'a ecrit nicolas. C'est bien TRUE qu'il faut passer a g_string_free() si tu n'as plus besoin de la chaine de caractere. Lui passer FALSE ben... ca peut par exemple servir si tu definis une fonction qui renvoie un gchar*, mais qui, en interne, utilise les facilites que procure un GString.

Sinon, ton programme provoque une erreur de segmentation, donc pour avoir une chance de savoir precisement d'ou elle vient, je te conseille d'utiliser un debugeur tel que gdb (http://www.gnu.org/software/gdb/). En tout cas, un SIGSEGV est davantage lie a un manque de malloc() qu'a un manque de free(), enfin je crois.

[Emmanuel Deloget]

Bonjour à tous!

J'espère que vous allez pouvoir m'aider : Je m'explique.

J'utilise la Glib pour la manipulation de chaine de caractères.

voici le code tout bete :

<snip>

Comment vraiment tout liberer?

glib n'est pas prévu pour tout libérer, c'est même l'exact contraire. C'est de cette manière que glib arrive à une efficacité certaine.

Le truc c'est que dans un programme un peu plus long, j'utilise pas mal de G_string et mon prog aléatoirement fait un SIGSEGV. le fichier core généré est peu explicite mais il y aurait bien un souci de fuite de memoire, d'ou mon interrogation sur ces bytes non desalloués. (la version GLib est la dernière)

MERCI

Je te promets que ton segfault n'est pas de la faute de glib (au mieux, c'est l'utilisation que tu en fait, auquel cas je te conseille de relire la doc de cette librairie).

La fuite de mémoire est normale - ce n'est pas une fuite de mémoire. La FAQ GTK+ est, je crois, assez explicite sur le sujet (il me semble qu'elle l'était du temps ou j'en assurait la maintenance; je suis persuadé d'avoir participé à la rédaction d'une réponse qui portait sur ce problème)*.

(edit: oups; ça parle de g_list, pas de g_string; cependant, le problème est similaire: Memory does not seem to be released when I free the list nodes I've allocated).

[Médinoc]

Ils ne précisent pas si c'est thread-safe, dans leur FAQ...

[Emmanuel Deloget]

Ils ne précisent pas si c'est thread-safe, dans leur FAQ...

Meuh si, quelque part d'autre. La réponse est "non". C'est pour ça que les mutex, etc, ont aussi été encapsulé, de manière à te permettre d'écrire le code thread safe toi même. Le choix au niveau design est simple: seul celui qui crée une application multithread sait comment il doit gérer ses données. Il est hors de question de lui imposer des lock/unlock de mutex alors qu'il n'en a peut être pas besoin.

[Médinoc]

Sauf que ces histoires d'allocateur ne devraient pas utiliser un système de lock/mutex, mais du TLS...