valgrind different resultat sur different OS

fakessh écrivit :

mes tests avec valgrind sur different os à savoir centos 5 et
6 me retournent des resultats differents

[...]

je ne sais pas bien analyser les resultats mais il y a de
grandes differences entre les deux plateformes

Est-ce que les bibliothèques (libc, libopenssl, etc.) sont les mêmes ?
Si ce ne sont pas les mêmes, il n'est pas utile de s'inquiêter outre
mesure, car en fait tu mesures les différences entre les deux systèmes
(qui peuvent parfaitement utiliser des algorithmes différents pour
l'allocation mémoire).

un nombre erreur qui varie du simple au double

Où lis-tu cela ?
Je lis d'une part
: =2073== ERROR SUMMARY: 0 errors from 0 contexts
et d'autre part
: =654== ERROR SUMMARY: 349 errors from 6 contexts

Autrement dit, dans le premier cas, tout va bien ; et dans le second,
plein d'erreurs.

et il semblerait qu il y a une fuite de memoire sur centos 5

Est-ce que tu fais référence à
: =2073== possibly lost: 36 bytes in 3 blocks

« Possibly » signifie que valgrind ne sait pas décider. Étant donné que
le même algorithme sur l'autre système ne déclenche plus le même
diagnostic, je pense que l'on peut considérer cela comme un biais du
premier système.

Par ailleurs, je pense qu'il est plus utile de se concentrer sur le
système récent pour développer ; il est certes utile de vérifier que ton
programme fonctionne bien sur l'ancienne version, mais essayer
d'améliorer le fonctionnement d'outils de débogage sur autre chose que
la dernière version du système ne va pas susciter l'enthousiasme de la
part des développeurs en charge de ces outils.


Antoine

Antoine Leca wrote:

fakessh écrivit :

mes tests avec valgrind sur different os à savoir centos 5

et

6 me retournent des resultats differents

[...]

je ne sais pas bien analyser les resultats mais il y a de
grandes differences entre les deux plateformes

Est-ce que les bibliothèques (libc, libopenssl, etc.) sont

les mêmes ?


les bibliotheques sont differentes
centos 5
~]# rpm -qa glibc
glibc-2.5-81.el5_8.2
~]# rpm -qa openssl
openssl-0.9.8e-22.el5_8.4

centos 6
~]# rpm -qa glibc
glibc-2.12-1.47.el6_2.12.i686
~]# rpm -qa openssl
openssl-1.0.0-20.el6_2.5.i686

Si ce ne sont pas les mêmes, il n'est pas utile de

s'inquiêter outre

mesure, car en fait tu mesures les différences entre les

deux systèmes

(qui peuvent parfaitement utiliser des algorithmes

différents pour

l'allocation mémoire).

un nombre erreur qui varie du simple au double

Où lis-tu cela ?
Je lis d'une part
: =2073== ERROR SUMMARY: 0 errors from 0 contexts
et d'autre part
: =654== ERROR SUMMARY: 349 errors from 6 contexts

Autrement dit, dans le premier cas, tout va bien ; et dans

le second,

plein d'erreurs.

à savoir centos 5
0 erreurs
et centos 6
349 erreurs


je ne comprends pas bien l extreme difference d erreurs
la logique veut que cela devrait etre la meme chose ou à peu
pres la meme chose

je pense que logiquement
un code c devrait logiquement reagit de la meme maniere
et pas 0 erreurs d un cote
et toutes les lignes du code en warning de l autre
j ai commence à regarder plus precisement les erreurs
et il semble que openssl en declenche beaucoup voir toutes
les erreurs
et le reste c est memset

et il semblerait qu il y a une fuite de memoire sur centos

5

Est-ce que tu fais référence à
: =2073== possibly lost: 36 bytes in 3 blocks

« Possibly » signifie que valgrind ne sait pas décider.

Étant donné que

à ce sujet la je possede 2 systemes centos 5
avec des noyaux custom
et sur la possibilite de perte j obtiens la aussi des
resultats differents
à savoir pas de perte et la petite perte en question possibly
lost: 36 bytes in 3 blocks
les executables sont compiles avec cette ligne de commande
gcc -Wall -O0 -ggdb3 -o smtp_openssl_client_stable
smtp_openssl.c -std=gnu99 -lssl

les differents uname -a de mes 2 systemes centos 5
~]# uname -a
Linux r*****.ovh.net 2.6.32.2-xxxx-grs-ipv6-32 #1 SMP Wed Dec
30 11:42:30 UTC 2009 i686 i686 i386 GNU/Linux
~]# uname -a
Linux ks******.kimsufi.com 2.6.34.6-xxxx-grs-ipv6-32 #3 SMP
Fri Sep 17 16:03:53 UTC 2010 i686 i686 i386 GNU/Linux

le même algorithme sur l'autre système ne déclenche plus le

même

diagnostic, je pense que l'on peut considérer cela comme un

biais du

premier système.

et sur mes erreurs tout les memset declenche une alarme sur
centos 6

ils sont mal ecrit il declenche un warning

donc comment faire pour bien ecrire les declarations
memset


et je remarque beaucoup d erreurs voir toutes les autres qui
proviennent de openssl
cela est important ou je ne dois pas y faire attention

Par ailleurs, je pense qu'il est plus utile de se

concentrer sur le

système récent pour développer ; il est certes utile de

vérifier que ton

programme fonctionne bien sur l'ancienne version, mais

essayer

d'améliorer le fonctionnement d'outils de débogage sur

autre chose que

la dernière version du système ne va pas susciter

l'enthousiasme de la

part des développeurs en charge de ces outils.


Antoine

fakessh @ wrote:

Antoine Leca wrote:

fakessh écrivit :

mes tests avec valgrind sur different os à savoir centos

5

et

6 me retournent des resultats differents

[...]

je ne sais pas bien analyser les resultats mais il y a de
grandes differences entre les deux plateformes

Est-ce que les bibliothèques (libc, libopenssl, etc.) sont

les mêmes ?


les bibliotheques sont differentes
centos 5
~]# rpm -qa glibc
glibc-2.5-81.el5_8.2
~]# rpm -qa openssl
openssl-0.9.8e-22.el5_8.4

centos 6
~]# rpm -qa glibc
glibc-2.12-1.47.el6_2.12.i686
~]# rpm -qa openssl
openssl-1.0.0-20.el6_2.5.i686

Si ce ne sont pas les mêmes, il n'est pas utile de

s'inquiêter outre

mesure, car en fait tu mesures les différences entre les

deux systèmes

(qui peuvent parfaitement utiliser des algorithmes

différents pour

l'allocation mémoire).

un nombre erreur qui varie du simple au double

Où lis-tu cela ?
Je lis d'une part
: =2073== ERROR SUMMARY: 0 errors from 0 contexts
et d'autre part
: =654== ERROR SUMMARY: 349 errors from 6 contexts

Autrement dit, dans le premier cas, tout va bien ; et dans

le second,

plein d'erreurs.

à savoir centos 5
0 erreurs
et centos 6
349 erreurs


je ne comprends pas bien l extreme difference d erreurs
la logique veut que cela devrait etre la meme chose ou à

peu

pres la meme chose

je pense que logiquement
un code c devrait logiquement reagit de la meme maniere
et pas 0 erreurs d un cote
et toutes les lignes du code en warning de l autre
j ai commence à regarder plus precisement les erreurs
et il semble que openssl en declenche beaucoup voir toutes
les erreurs
et le reste c est memset

et il semblerait qu il y a une fuite de memoire sur

centos

5

Est-ce que tu fais référence à
: =2073== possibly lost: 36 bytes in 3 blocks

« Possibly » signifie que valgrind ne sait pas décider.

Étant donné que

à ce sujet la je possede 2 systemes centos 5
avec des noyaux custom
et sur la possibilite de perte j obtiens la aussi des
resultats differents
à savoir pas de perte et la petite perte en question

possibly

lost: 36 bytes in 3 blocks
les executables sont compiles avec cette ligne de commande
gcc -Wall -O0 -ggdb3 -o smtp_openssl_client_stable
smtp_openssl.c -std=gnu99 -lssl

les differents uname -a de mes 2 systemes centos 5
~]# uname -a
Linux r*****.ovh.net 2.6.32.2-xxxx-grs-ipv6-32 #1 SMP Wed

Dec

30 11:42:30 UTC 2009 i686 i686 i386 GNU/Linux
~]# uname -a
Linux ks******.kimsufi.com 2.6.34.6-xxxx-grs-ipv6-32 #3 SMP
Fri Sep 17 16:03:53 UTC 2010 i686 i686 i386 GNU/Linux

le même algorithme sur l'autre système ne déclenche plus

le

même

diagnostic, je pense que l'on peut considérer cela comme

un

biais du

premier système.

et sur mes erreurs tout les memset declenche une alarme sur
centos 6

ils sont mal ecrit il declenche un warning

donc comment faire pour bien ecrire les declarations
memset


et je remarque beaucoup d erreurs voir toutes les autres

qui

proviennent de openssl
cela est important ou je ne dois pas y faire attention

Par ailleurs, je pense qu'il est plus utile de se

concentrer sur le

système récent pour développer ; il est certes utile de

vérifier que ton

programme fonctionne bien sur l'ancienne version, mais

essayer

d'améliorer le fonctionnement d'outils de débogage sur

autre chose que

la dernière version du système ne va pas susciter

l'enthousiasme de la

part des développeurs en charge de ces outils.


Antoine

je dirais meme plus un de mes systemes centos 5
me retourne 3 erreurs
~]$ valgrind --tool=memcheck --leak-check=full
./smtp_openssl_client_stable
=–77== Memcheck, a memory error detector
=–77== Copyright (C) 2002-2009, and GNU GPL'd, by Julian
Seward et al.
=–77== Using Valgrind-3.5.0 and LibVEX; rerun with -h for
copyright info
=–77== Command: ./smtp_openssl_client_stable
=–77==
connecting smtp server
220-ks37777.kimsufi.com ESMTP Postfix (2.9.3)
220-
220-System Info: This is a Postfix mail server
220-running a multiline SMTP greeting patch
220-
220-Further Info: See http://www.postfix.org
220-
220-Site Contact: fakessh @, Postmaster
220-Email: <postmaster@fakessh.eu>
220-Fax : +33-9-7213-4187
220 Please don't send me SPAM here - we don't like it

250-ks37777.kimsufi.com
250-PIPELINING
250-SIZE 20480000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

220 2.0.0 Ready to start TLS

250-ks37777.kimsufi.com
250-PIPELINING
250-SIZE 20480000
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

334 VXNlcm5hbWU6

334 UGFzc3dvcmQ6

235 2.7.0 Authentication successful

250 2.1.0 Ok

250 2.1.5 Ok

354 End data with <CR><LF>.<CR><LF>

250 2.0.0 Ok: queued as 3W7YPS3jg7zsdCQ

mail send!
221 2.0.0 Bye

=–77==
=–77== HEAP SUMMARY:
=–77== in use at exit: 29,392 bytes in 2,002 blocks
=–77== total heap usage: 2,720 allocs, 718 frees, 185,730
bytes allocated
=–77==
=–77== 12 bytes in 1 blocks are possibly lost in loss
record 73 of 205
=–77== at 0x4005B83: malloc (vg_replace_malloc.c:195)
=–77== by 0x4A68352D: ??? (in /lib/libcrypto.so.0.9.8e)
=–77== by 0x4A683BDE: CRYPTO_malloc (in
/lib/libcrypto.so.0.9.8e)
=–77== by 0x4A6132D6: lh_insert (in
/lib/libcrypto.so.0.9.8e)
=–77== by 0x4A61448D: ??? (in /lib/libcrypto.so.0.9.8e)
=–77== by 0x4A614081: ERR_load_strings (in
/lib/libcrypto.so.0.9.8e)
=–77== by 0x4A64C3DB: ERR_load_X509V3_strings (in
/lib/libcrypto.so.0.9.8e)
=–77== by 0x4A614A59: ERR_load_crypto_strings (in
/lib/libcrypto.so.0.9.8e)
=–77== by 0x4A721966: SSL_load_error_strings (in
/lib/libssl.so.0.9.8e)
=–77== by 0x8048F84: sendemail (smtp_openssl.c:147)
=–77== by 0x8048C51: main (smtp_openssl.c:56)
=–77==
=–77== 12 bytes in 1 blocks are possibly lost in loss
record 74 of 205
=–77== at 0x4005B83: malloc (vg_replace_malloc.c:195)
=–77== by 0x4A68352D: ??? (in /lib/libcrypto.so.0.9.8e)
=–77== by 0x4A683BDE: CRYPTO_malloc (in
/lib/libcrypto.so.0.9.8e)
=–77== by 0x4A6132D6: lh_insert (in
/lib/libcrypto.so.0.9.8e)
=–77== by 0x4A61448D: ??? (in /lib/libcrypto.so.0.9.8e)
=–77== by 0x4A614081: ERR_load_strings (in
/lib/libcrypto.so.0.9.8e)
=–77== by 0x4A601D5B: ERR_load_DSO_strings (in
/lib/libcrypto.so.0.9.8e)
=–77== by 0x4A614A69: ERR_load_crypto_strings (in
/lib/libcrypto.so.0.9.8e)
=–77== by 0x4A721966: SSL_load_error_strings (in
/lib/libssl.so.0.9.8e)
=–77== by 0x8048F84: sendemail (smtp_openssl.c:147)
=–77== by 0x8048C51: main (smtp_openssl.c:56)
=–77==
=–77== 12 bytes in 1 blocks are possibly lost in loss
record 75 of 205
=–77== at 0x4005B83: malloc (vg_replace_malloc.c:195)
=–77== by 0x4A68352D: ??? (in /lib/libcrypto.so.0.9.8e)
=–77== by 0x4A683BDE: CRYPTO_malloc (in
/lib/libcrypto.so.0.9.8e)
=–77== by 0x4A6132D6: lh_insert (in
/lib/libcrypto.so.0.9.8e)
=–77== by 0x4A61448D: ??? (in /lib/libcrypto.so.0.9.8e)
=–77== by 0x4A614081: ERR_load_strings (in
/lib/libcrypto.so.0.9.8e)
=–77== by 0x4A602BDB: ERR_load_ENGINE_strings (in
/lib/libcrypto.so.0.9.8e)
=–77== by 0x4A614A6E: ERR_load_crypto_strings (in
/lib/libcrypto.so.0.9.8e)
=–77== by 0x4A721966: SSL_load_error_strings (in
/lib/libssl.so.0.9.8e)
=–77== by 0x8048F84: sendemail (smtp_openssl.c:147)
=–77== by 0x8048C51: main (smtp_openssl.c:56)
=–77==
=–77== LEAK SUMMARY:
=–77== definitely lost: 0 bytes in 0 blocks
=–77== indirectly lost: 0 bytes in 0 blocks
=–77== possibly lost: 36 bytes in 3 blocks
=–77== still reachable: 29,356 bytes in 1,999 blocks
=–77== suppressed: 0 bytes in 0 blocks
=–77== Reachable blocks (those to which a pointer was
found) are not shown.
=–77== To see them, rerun with: --leak-check=full --show-
reachable=yes
=–77==
=–77== For counts of detected and suppressed errors, rerun
with: -v
=–77== ERROR SUMMARY: 3 errors from 3 contexts (suppressed:
29 from 10)


et l autre 0 erreurs
~]$ valgrind --tool=memcheck --leak-check=full
./smtp_openssl_client_stable
=010== Memcheck, a memory error detector
=010== Copyright (C) 2002-2009, and GNU GPL'd, by Julian
Seward et al.
=010== Using Valgrind-3.5.0 and LibVEX; rerun with -h for
copyright info
=010== Command: ./smtp_openssl_client_stable
=010==
connecting smtp server
220-ks37777.kimsufi.com ESMTP Postfix (2.9.3)
220-
220-System Info: This is a Postfix mail server
220-running a multiline SMTP greeting patch
220-
220-Further Info: See http://www.postfix.org
220-
220-Site Contact: fakessh @, Postmaster
220-Email: <postmaster@fakessh.eu>
220-Fax : +33-9-7213-4187
220 Please don't send me SPAM here - we don't like it

250-ks37777.kimsufi.com
250-PIPELINING
250-SIZE 20480000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

220 2.0.0 Ready to start TLS

250-ks37777.kimsufi.com
250-PIPELINING
250-SIZE 20480000
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

334 VXNlcm5hbWU6

334 UGFzc3dvcmQ6

235 2.7.0 Authentication successful

250 2.1.0 Ok

250 2.1.5 Ok

354 End data with <CR><LF>.<CR><LF>

250 2.0.0 Ok: queued as 3W7YQm2r8dzsdCf

mail send!
221 2.0.0 Bye

=010==
=010== HEAP SUMMARY:
=010== in use at exit: 29,392 bytes in 2,002 blocks
=010== total heap usage: 2,720 allocs, 718 frees,
185,730 bytes allocated
=010==
=010== LEAK SUMMARY:
=010== definitely lost: 0 bytes in 0 blocks
=010== indirectly lost: 0 bytes in 0 blocks
=010== possibly lost: 0 bytes in 0 blocks
=010== still reachable: 29,392 bytes in 2,002 blocks
=010== suppressed: 0 bytes in 0 blocks
=010== Reachable blocks (those to which a pointer was
found) are not shown.
=010== To see them, rerun with: --leak-check=full --show-
reachable=yes
=010==
=010== For counts of detected and suppressed errors, rerun
with: -v
=010== ERROR SUMMARY: 0 errors from 0 contexts
(suppressed: 31 from 10)


alors comme les resultats sont different de une machine à une
autre comment bien ecrire le C

je vous remrcie pour toutes vos futures reponses