Anonyme

12 mai 2011 à 14:17:34

Bonjour,

Je code actuellement un projet en système et mon professeur me conseille readline afin de lire les entrées de l'utilisateur pour simuler les conditions d'un terminal.

Seulement, valgrind me précise une fuite mémoire importante en provenance de readline.

je me suis renseigné et cela semble normal et sans solution.

J'aimerais néanmoins confirmé que c'est sans espoir de trouver une solution car je déteste laisser une fuite mémoire dans mes programmes.

Merci de votre compréhension.

kerloi

12 mai 2011 à 14:48:41

Salut,

Citation : Man page

readline will read a line from the terminal and return it, using prompt
as a prompt. If prompt is NULL or the empty string, no prompt is
issued. The line returned is allocated with malloc(3); the caller must
free it when finished. The line returned has the final newline
removed, so only the text of the line remains.

Donc si tu n'alloue pas toi même la chaine, tu dois appeler free sur la chaine de retour lorsque tu as fini de travailler avec.

Anonyme

12 mai 2011 à 17:00:49

En effet, cela permet de libérer toute la mémoire que valgrind considère comme définitivement perdu mais la la mémoire qui peut être rechargé.

je vous poste le retour de valgrind:

==11744== 
==11744== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 29 from 1)
==11744== malloc/free: in use at exit: 55,905 bytes in 166 blocks.
==11744== malloc/free: 403 allocs, 237 frees, 71,108 bytes allocated.
==11744== For counts of detected errors, rerun with: -v
==11744== searching for pointers to 166 not-freed blocks.
==11744== checked 131,180 bytes.
==11744== 
==11744== 14 bytes in 1 blocks are still reachable in loss record 1 of 11
==11744==    at 0x4023E8C: realloc (vg_replace_malloc.c:429)
==11744==    by 0x408265F: _nc_doalloc (doalloc.c:50)
==11744==    by 0x40871A1: get_space (lib_tparm.c:132)
==11744==    by 0x408766F: tparm (lib_tparm.c:168)
==11744==    by 0x408BEBF: _nc_trim_sgr0 (trim_sgr0.c:54)
==11744==    by 0x40864DE: tgetent (lib_termcap.c:156)
==11744==    by 0x404A192: _rl_init_terminal_io (terminal.c:452)
==11744==    by 0x4034496: rl_initialize (readline.c:1027)
==11744==    by 0x40353AD: readline (readline.c:313)
==11744==    by 0x804A57D: main (list.c:187)
==11744== 
==11744== 
==11744== 14 bytes in 2 blocks are still reachable in loss record 2 of 11
==11744==    at 0x4023D6E: malloc (vg_replace_malloc.c:207)
==11744==    by 0x413645F: strdup (strdup.c:43)
==11744==    by 0x40859E9: _nc_setupterm (lib_setup.c:585)
==11744==    by 0x4086361: tgetent (lib_termcap.c:88)
==11744==    by 0x404A192: _rl_init_terminal_io (terminal.c:452)
==11744==    by 0x4034496: rl_initialize (readline.c:1027)
==11744==    by 0x40353AD: readline (readline.c:313)
==11744==    by 0x804A57D: main (list.c:187)
==11744== 
==11744== 
==11744== 31 bytes in 1 blocks are still reachable in loss record 3 of 11
==11744==    at 0x4023D6E: malloc (vg_replace_malloc.c:207)
==11744==    by 0x4082A2E: _nc_home_terminfo (home_terminfo.c:57)
==11744==    by 0x408256C: _nc_next_db (db_iterator.c:166)
==11744==    by 0x408AFF9: _nc_read_entry (read_entry.c:530)
==11744==    by 0x408535E: grab_entry (lib_setup.c:360)
==11744==    by 0x40859A8: _nc_setupterm (lib_setup.c:556)
==11744==    by 0x4086361: tgetent (lib_termcap.c:88)
==11744==    by 0x404A192: _rl_init_terminal_io (terminal.c:452)
==11744==    by 0x4034496: rl_initialize (readline.c:1027)
==11744==    by 0x40353AD: readline (readline.c:313)
==11744==    by 0x804A57D: main (list.c:187)
==11744== 
==11744== 
==11744== 44 bytes in 1 blocks are still reachable in loss record 4 of 11
==11744==    at 0x4021E22: calloc (vg_replace_malloc.c:397)
==11744==    by 0x408A294: _nc_read_termtype (read_entry.c:186)
==11744==    by 0x408AE9A: _nc_read_file_entry (read_entry.c:379)
==11744==    by 0x408B06D: _nc_read_entry (read_entry.c:415)
==11744==    by 0x408535E: grab_entry (lib_setup.c:360)
==11744==    by 0x40859A8: _nc_setupterm (lib_setup.c:556)
==11744==    by 0x4086361: tgetent (lib_termcap.c:88)
==11744==    by 0x404A192: _rl_init_terminal_io (terminal.c:452)
==11744==    by 0x4034496: rl_initialize (readline.c:1027)
==11744==    by 0x40353AD: readline (readline.c:313)
==11744==    by 0x804A57D: main (list.c:187)
==11744== 
==11744== 
==11744== 78 bytes in 1 blocks are still reachable in loss record 5 of 11
==11744==    at 0x4021E22: calloc (vg_replace_malloc.c:397)
==11744==    by 0x408A304: _nc_read_termtype (read_entry.c:201)
==11744==    by 0x408AE9A: _nc_read_file_entry (read_entry.c:379)
==11744==    by 0x408B06D: _nc_read_entry (read_entry.c:415)
==11744==    by 0x408535E: grab_entry (lib_setup.c:360)
==11744==    by 0x40859A8: _nc_setupterm (lib_setup.c:556)
==11744==    by 0x4086361: tgetent (lib_termcap.c:88)
==11744==    by 0x404A192: _rl_init_terminal_io (terminal.c:452)
==11744==    by 0x4034496: rl_initialize (readline.c:1027)
==11744==    by 0x40353AD: readline (readline.c:313)
==11744==    by 0x804A57D: main (list.c:187)
==11744== 
==11744== 
==11744== 83 bytes in 1 blocks are still reachable in loss record 6 of 11
==11744==    at 0x4023D6E: malloc (vg_replace_malloc.c:207)
==11744==    by 0x4082682: _nc_doalloc (doalloc.c:55)
==11744==    by 0x40873DE: _nc_tparm_analyze (lib_tparm.c:352)
==11744==    by 0x4087573: tparm (lib_tparm.c:478)
==11744==    by 0x408BEBF: _nc_trim_sgr0 (trim_sgr0.c:54)
==11744==    by 0x40864DE: tgetent (lib_termcap.c:156)
==11744==    by 0x404A192: _rl_init_terminal_io (terminal.c:452)
==11744==    by 0x4034496: rl_initialize (readline.c:1027)
==11744==    by 0x40353AD: readline (readline.c:313)
==11744==    by 0x804A57D: main (list.c:187)
==11744== 
==11744== 
==11744== 172 bytes in 1 blocks are still reachable in loss record 7 of 11
==11744==    at 0x4021E22: calloc (vg_replace_malloc.c:397)
==11744==    by 0x4085991: _nc_setupterm (lib_setup.c:549)
==11744==    by 0x4086361: tgetent (lib_termcap.c:88)
==11744==    by 0x404A192: _rl_init_terminal_io (terminal.c:452)
==11744==    by 0x4034496: rl_initialize (readline.c:1027)
==11744==    by 0x40353AD: readline (readline.c:313)
==11744==    by 0x804A57D: main (list.c:187)
==11744== 
==11744== 
==11744== 512 bytes in 1 blocks are still reachable in loss record 8 of 11
==11744==    at 0x4023E8C: realloc (vg_replace_malloc.c:429)
==11744==    by 0x404DB57: xrealloc (xmalloc.c:73)
==11744==    by 0x403842F: rl_add_funmap_entry (funmap.c:200)
==11744==    by 0x4038482: rl_initialize_funmap (funmap.c:223)
==11744==    by 0x40344AB: rl_initialize (readline.c:1033)
==11744==    by 0x40353AD: readline (readline.c:313)
==11744==    by 0x804A57D: main (list.c:187)
==11744== 
==11744== 
==11744== 1,347 bytes in 1 blocks are still reachable in loss record 9 of 11
==11744==    at 0x4023D6E: malloc (vg_replace_malloc.c:207)
==11744==    by 0x408A1C4: _nc_read_termtype (read_entry.c:161)
==11744==    by 0x408AE9A: _nc_read_file_entry (read_entry.c:379)
==11744==    by 0x408B06D: _nc_read_entry (read_entry.c:415)
==11744==    by 0x408535E: grab_entry (lib_setup.c:360)
==11744==    by 0x40859A8: _nc_setupterm (lib_setup.c:556)
==11744==    by 0x4086361: tgetent (lib_termcap.c:88)
==11744==    by 0x404A192: _rl_init_terminal_io (terminal.c:452)
==11744==    by 0x4034496: rl_initialize (readline.c:1027)
==11744==    by 0x40353AD: readline (readline.c:313)
==11744==    by 0x804A57D: main (list.c:187)
==11744== 
==11744== 
==11744== 1,656 bytes in 1 blocks are still reachable in loss record 10 of 11
==11744==    at 0x4021E22: calloc (vg_replace_malloc.c:397)
==11744==    by 0x408A386: _nc_read_termtype (read_entry.c:207)
==11744==    by 0x408AE9A: _nc_read_file_entry (read_entry.c:379)
==11744==    by 0x408B06D: _nc_read_entry (read_entry.c:415)
==11744==    by 0x408535E: grab_entry (lib_setup.c:360)
==11744==    by 0x40859A8: _nc_setupterm (lib_setup.c:556)
==11744==    by 0x4086361: tgetent (lib_termcap.c:88)
==11744==    by 0x404A192: _rl_init_terminal_io (terminal.c:452)
==11744==    by 0x4034496: rl_initialize (readline.c:1027)
==11744==    by 0x40353AD: readline (readline.c:313)
==11744==    by 0x804A57D: main (list.c:187)
==11744== 
==11744== 
==11744== 51,954 bytes in 155 blocks are still reachable in loss record 11 of 11
==11744==    at 0x4023D6E: malloc (vg_replace_malloc.c:207)
==11744==    by 0x404DBCC: xmalloc (xmalloc.c:60)
==11744==    by 0x40345BF: rl_initialize (readline.c:1022)
==11744==    by 0x40353AD: readline (readline.c:313)
==11744==    by 0x804A57D: main (list.c:187)
==11744== 
==11744== LEAK SUMMARY:
==11744==    definitely lost: 0 bytes in 0 blocks.
==11744==      possibly lost: 0 bytes in 0 blocks.
==11744==    still reachable: 55,905 bytes in 166 blocks.
==11744==         suppressed: 0 bytes in 0 blocks.

kerloi

12 mai 2011 à 18:34:25

Si le sujet est résolu signale le

Anonyme

12 mai 2011 à 19:59:35

Bah justement l'objectif de ma question était de libérer cette mémoire en still reachable.

Y a t'il une solution?

kerloi

12 mai 2011 à 23:13:22

Il me faut un échantillon de ton code pour le savoir.

Si valgrind dit "still reachable" c'est que les zones mémoires sont encore pointés par nue variable mais reste à voire si c'est de ta faute ou pas

Anonyme

15 mai 2011 à 13:21:25

Et bien comme je l'ai dis la fuit mémoire provient de readline comme vous pouvez le constater avec valgrind. Je peux vous donner mon code mais cela ne vous avancera à rien...

C'est à l'initialisation de readline qu'il fait ces allocations et le fait qu'une fuite mémoire soit présente est semble t'il normal.

C'est juste que n'aimant pas aoir de fuite mémoire (même si je n'en suis as le responsable) je voulais juste savoir s'il y a une solution.

Voila pourquoi mon code ne vous avancera pas: j'y suis pour rien.

Pouet_forever

15 mai 2011 à 13:30:00

Tu utilises quel distribution et quelle version de la glibc ?
Le mieux est encore d'aller voir les sources.

kerloi

15 mai 2011 à 18:18:50

Ouaip cela semble normal (cf ici).
Mais si tu te réfères à la doc de valgrind :

Citation : Valgrind manual

Indirectly lost and still reachable blocks are not counted as true "errors", even if --show-reachable=yes is specified and they are printed; this is because such blocks don't need direct fixing by the programmer.

EnzoDeg40

21 mars 2024 à 14:49:58

int main()
{
	char	*line;
	
	line = readline("sesh> ");
	free(line);
	return (0);
}

➜  henzolab git:(edegraev) ✗ valgrind ./a.out          
==446318== Memcheck, a memory error detector
==446318== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==446318== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==446318== Command: ./a.out
==446318== 
sesh> a
==446318== 
==446318== HEAP SUMMARY:
==446318==     in use at exit: 204,155 bytes in 221 blocks
==446318==   total heap usage: 429 allocs, 208 frees, 224,707 bytes allocated
==446318== 
==446318== LEAK SUMMARY:
==446318==    definitely lost: 0 bytes in 0 blocks
==446318==    indirectly lost: 0 bytes in 0 blocks
==446318==      possibly lost: 0 bytes in 0 blocks
==446318==    still reachable: 204,155 bytes in 221 blocks
==446318==         suppressed: 0 bytes in 0 blocks
==446318== Rerun with --leak-check=full to see details of leaked memory
==446318== 
==446318== For lists of detected and suppressed errors, rerun with: -s
==446318== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Je suis actuellement bloqué sur probleme, meme avec un free le problème est toujours présent

michelbillaud

21 mars 2024 à 15:19:13

Pas grand chose à y faire.

Au moins une raison : à ce que je vois (strace) readline (qui fait de l'édition de ligne) a besoin de charger la description (terminfo) du type de terminal associé à la sortie

access("/lib/terminfo/x/xterm-256color", R_OK) = 0
openat(AT_FDCWD, "/lib/terminfo/x/xterm-256color", O_RDONLY) = 3

pour savoir comment déplacer le curseur, effacer des caractères etc.

Et pour des raisons évidentes de performances, il ne le fait qu'une fois au premier readline, et la réutilise pendant la durée d'exécution du programme.

Par ailleurs c'est pas une fuite. lost = 0.

PS: y a ça, et aussi le fait qu'il garde un historique des lignes déjà tapées.

https://stackoverflow.com/questions/55196451/gnu-readline-enormous-memory-leak

-
Edité par michelbillaud 21 mars 2024 à 15:25:32

AbcAbc6

21 mars 2024 à 18:22:16

@EnzoDeg40 Bonjour, merci de ne pas déterrer d'ancien sujet pour une nouvelle question, créer votre propre sujet dans les règles du forum à savoir qu'un message commence par des règles de politesses (un bonjour ou des salutations et se termine par des remerciements par avances pour les futures réponses).

Déterrage

Citation des règles générales du forum :

Avant de poster un message, vérifiez la date du sujet dans lequel vous comptiez intervenir.

Si le dernier message sur le sujet date de plus de deux mois, mieux vaut ne pas répondre.
En effet, le déterrage d'un sujet nuit au bon fonctionnement du forum, et l'informatique pouvant grandement changer en quelques mois il n'est donc que rarement pertinent de déterrer un vieux sujet.

Au lieu de déterrer un sujet il est préférable :

soit de contacter directement le membre voulu par messagerie privée en cliquant sur son pseudonyme pour accéder à sa page profil, puis sur le lien "Ecrire un message"

soit de créer un nouveau sujet décrivant votre propre contexte

ne pas répondre à un déterrage et le signaler à la modération

Liens conseillés

Je ferme ici.

Forums des Zéros

Fuites Mémoire liés à readline

Déterrage

Liens conseillés

Fuites Mémoire liés à readline

Déterrage

Liens conseillés

Supprimer

Modérer

Signaler le message aux modérateurs