Ubuntu-fr

Nuliel

fuites mémoire des outils classiques?

Bonjour,
Ma question est un peu nulle, mais pourquoi valgrind trouve des fuites sur des programmes de base comme grep?

nuliel@nuliel-desktop:~$ valgrind --leak-check=full grep bidule test
==23338== Memcheck, a memory error detector
==23338== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==23338== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==23338== Command: grep bidule test
==23338== 
bidule
==23338== 
==23338== HEAP SUMMARY:
==23338==     in use at exit: 114,055 bytes in 38 blocks
==23338==   total heap usage: 170 allocs, 132 frees, 142,699 bytes allocated
==23338== 
==23338== 128 bytes in 1 blocks are possibly lost in loss record 18 of 26
==23338==    at 0x483AD7B: realloc (vg_replace_malloc.c:834)
==23338==    by 0x12A641: ??? (in /usr/bin/grep)
==23338==    by 0x10E5CF: ??? (in /usr/bin/grep)
==23338==    by 0x10D66F: ??? (in /usr/bin/grep)
==23338==    by 0x4908D09: (below main) (libc-start.c:308)
==23338== 
==23338== 856 (224 direct, 632 indirect) bytes in 1 blocks are definitely lost in loss record 21 of 26
==23338==    at 0x48386AF: malloc (vg_replace_malloc.c:306)
==23338==    by 0x483ADE7: realloc (vg_replace_malloc.c:834)
==23338==    by 0x49C4098: re_compile_internal (regcomp.c:750)
==23338==    by 0x49C42CA: re_compile_pattern (regcomp.c:230)
==23338==    by 0x10E31C: ??? (in /usr/bin/grep)
==23338==    by 0x10E61A: ??? (in /usr/bin/grep)
==23338==    by 0x10D66F: ??? (in /usr/bin/grep)
==23338==    by 0x4908D09: (below main) (libc-start.c:308)
==23338== 
==23338== LEAK SUMMARY:
==23338==    definitely lost: 224 bytes in 1 blocks
==23338==    indirectly lost: 632 bytes in 16 blocks
==23338==      possibly lost: 128 bytes in 1 blocks
==23338==    still reachable: 113,071 bytes in 20 blocks
==23338==         suppressed: 0 bytes in 0 blocks
==23338== Reachable blocks (those to which a pointer was found) are not shown.
==23338== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==23338== 
==23338== For lists of detected and suppressed errors, rerun with: -s
==23338== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
nuliel@nuliel-desktop:~$

C'est un oubli ou la mémoire est libérée plus tard?

---

[ poster un retour de commande ] [ poster une photo ]

Amiralgaby

Re : fuites mémoire des outils classiques?

Salut,
Je n'ai jamais testé auparavant mais j'aimerais bien la réponse aussi.
Sinon je pense que les outils venant de RedoxOS écrit en Rust sont moins capables de faire des leaks.

Il y a donc deux questions :
est-ce que le kernel à un garbage collector ?
est-ce que ces fuites ont une utilité ?

---

Vive la communauté du Libre !!!

Nuliel

Re : fuites mémoire des outils classiques?

est-ce que le kernel à un garbage collector ?

Non, il ne faut pas oublier les free quand on bosse en espace noyau (j'ai pu le constater avec un module noyau il y a quelques semaines)

Aucune fuite n'a d'utilité.
Là grep est exécuté en espace utilisateur (espace habituel), honnêtement j'imagine que la mémoire restante est vidée plus tard pour gagner un poil de performances, après je ne suis pas sûr du tout.

---

[ poster un retour de commande ] [ poster une photo ]

kamaris

Re : fuites mémoire des outils classiques?

Je me demande si ça vient bien de grep, ou de glibc.
Chez moi (sous Arch) :

==53159== Memcheck, a memory error detector
==53159== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==53159== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info
==53159== Command: grep z /home/user/f
==53159== 
==53159== 
==53159== HEAP SUMMARY:
==53159==     in use at exit: 112,714 bytes in 28 blocks
==53159==   total heap usage: 2,508 allocs, 2,480 frees, 257,020 bytes allocated
==53159== 
==53159== 128 bytes in 1 blocks are possibly lost in loss record 20 of 26
==53159==    at 0x484383F: realloc (vg_replace_malloc.c:1192)
==53159==    by 0x122B22: ??? (in /usr/bin/grep)
==53159==    by 0x10DB88: ??? (in /usr/bin/grep)
==53159==    by 0x10CDB4: ??? (in /usr/bin/grep)
==53159==    by 0x48EEB24: (below main) (in /usr/lib/libc-2.33.so)
==53159== 
==53159== 480 (224 direct, 256 indirect) bytes in 1 blocks are definitely lost in loss record 22 of 26
==53159==    at 0x483E6D5: malloc (vg_replace_malloc.c:379)
==53159==    by 0x49A9630: re_compile_internal (in /usr/lib/libc-2.33.so)
==53159==    by 0x49A984E: re_compile_pattern (in /usr/lib/libc-2.33.so)
==53159==    by 0x10D8D7: ??? (in /usr/bin/grep)
==53159==    by 0x10DBDA: ??? (in /usr/bin/grep)
==53159==    by 0x10CDB4: ??? (in /usr/bin/grep)
==53159==    by 0x48EEB24: (below main) (in /usr/lib/libc-2.33.so)
==53159== 
==53159== LEAK SUMMARY:
==53159==    definitely lost: 224 bytes in 1 blocks
==53159==    indirectly lost: 256 bytes in 11 blocks
==53159==      possibly lost: 128 bytes in 1 blocks
==53159==    still reachable: 112,106 bytes in 15 blocks
==53159==         suppressed: 0 bytes in 0 blocks
==53159== Reachable blocks (those to which a pointer was found) are not shown.
==53159== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==53159== 
==53159== For lists of detected and suppressed errors, rerun with: -s
==53159== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

Il faudrait jeter un coup d'œil au code pour savoir, en recompilant grep en mode debug si possible, ce que je ne ferai pas…