# [valgrind] [glibc]

## yohann

Bonjour, 

lorsque je compile le plus simple exécutable en c et que je le lance avec valgrind, j'ai une tripoté d'erreurs provenant de la glibc comme quoi une valeur n'est pas initialisée.

même valgrind ls me donne ce genre d'érreur:

```

valgrind ls

==10292== Use of uninitialised value of size 8

==10292==    at 0x53425DD: (within /lib64/libc-2.10.1.so)

==10292==    by 0x5342111: (within /lib64/libc-2.10.1.so)

==10292==    by 0x4A1E61C: _vgnU_freeres (in /usr/lib64/valgrind/amd64-linux/vgpreload_core.so)

==10292==    by 0x526EE84: (within /lib64/libc-2.10.1.so)

==10292==    by 0x526EEF4: exit (in /lib64/libc-2.10.1.so)

==10292==    by 0x408415: (within /bin/ls)

==10292==    by 0x5258A25: (below main) (in /lib64/libc-2.10.1.so)

==10292== 

...

ce bloc est répété plusieurs centaines (milliers?) de fois

...

==10292== ERROR SUMMARY: 14744 errors from 473 contexts (suppressed: 0 from 0)

==10292== malloc/free: in use at exit: 20,206 bytes in 14 blocks.

==10292== malloc/free: 46 allocs, 32 frees, 56,945 bytes allocated.

==10292== For counts of detected errors, rerun with: -v

==10292== Use --track-origins=yes to see where uninitialised values come from

==10292== searching for pointers to 14 not-freed blocks.

==10292== checked 107,920 bytes.

```

lien vers le post parlant de ce probleme:

https://bugs.gentoo.org/274771

J'essaye donc d'ajouter FEATURES="splitdebug" dans /etc/make.conf, 

puis emerge -aDNuv world

mais apparament rien ne change, de plus eix glibc ne semble pas indiquer la presence d'un flag splitdebug (mais en meme temps est-ce que FEATURES signifie qu'il doit y avoir un flag correspondant).

Enfin, je précise que mon architecture est AMD64

edit:

grace à Kazuya (https://forums.gentoo.org/viewtopic-t-814315.html)

Je crois avoir compris pourquoi FEATURES="splitdebug" ne change rien à mon probleme (parce que glibc a un RESTRICT strip et donc le débug est forcément inclut dedans)

mais cela veut donc dire que la glibc2.10.1 est belle et bien bugguée sur AMD64 (j'ai pas vraiment compris l'idée des *strlen() présenté dans le rapport de bug, apparament passer sur la version 2.11 de la glibc serait le moyen de résoudre le probleme, mais est-ce une bonne idée que d'utiliser une version instable de la glibc ?

----------

## Leander256

Salut,

 *yohann wrote:*   

> J'essaye donc d'ajouter FEATURES="splitdebug" dans /etc/make.conf, 
> 
> puis emerge -aDNuv world
> 
> mais apparament rien ne change, de plus eix glibc ne semble pas indiquer la presence d'un flag splitdebug (mais en meme temps est-ce que FEATURES signifie qu'il doit y avoir un flag correspondant).

 

FEATURES est une variable de Portage, tout comme USE. Donc ce que tu rajoutes dans FEATURES est complètement indépendant de USE. Donc il te faudrait plutôt un emerge -e world pour au final tout recompiler. Mais tu peux te contenter de faire emerge glibc pour voir, dans un premier temps.

 *yohann wrote:*   

> mais cela veut donc dire que la glibc2.10.1 est belle et bien bugguée sur AMD64 (j'ai pas vraiment compris l'idée des *strlen() présenté dans le rapport de bug, apparament passer sur la version 2.11 de la glibc serait le moyen de résoudre le probleme, mais est-ce une bonne idée que d'utiliser une version instable de la glibc ?

 

D'après le rapport de bug il ne s'agit pas d'un bug de la glibc mais d'une optimisation que valgrind ne comprend pas. Et si je comprends bien ce que ça raconte, il faut activer le USE debug mais désactiver le FEATURES splitdebug pour que valgrind ne râle pas. Je te conseille donc de tester cette combinaison avant de songer à passer une partie de ton système en ~amd64.

----------

