Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

valgrind different resultat sur different OS

3 réponses
Avatar
fakessh
hello les gurus du C

je travaille toujours sur mon petit projet en c
je me sers maintenant de openssl pour encoder mes donnees en
base64
mon dernier code est disponible içi

https://raw.github.com/fakessh/openprojectssl/master/smtp_openssl.c

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

centos 5
==32073==
==32073== HEAP SUMMARY:
==32073== in use at exit: 29,392 bytes in 2,002 blocks
==32073== total heap usage: 2,720 allocs, 718 frees,
185,730 bytes allocated
==32073==
==32073== LEAK SUMMARY:
==32073== definitely lost: 0 bytes in 0 blocks
==32073== indirectly lost: 0 bytes in 0 blocks
==32073== possibly lost: 36 bytes in 3 blocks
==32073== still reachable: 29,356 bytes in 1,999 blocks
==32073== suppressed: 0 bytes in 0 blocks
==32073== Rerun with --leak-check=full to see details of
leaked memory
==32073==
==32073== For counts of detected and suppressed errors, rerun
with: -v
==32073== ERROR SUMMARY: 0 errors from 0 contexts
(suppressed: 29 from 10)


centos 6
==18654==
==18654== HEAP SUMMARY:
==18654== in use at exit: 39,320 bytes in 2,485 blocks
==18654== total heap usage: 3,500 allocs, 1,015 frees,
825,327 bytes allocated
==18654==
==18654== LEAK SUMMARY:
==18654== definitely lost: 0 bytes in 0 blocks
==18654== indirectly lost: 0 bytes in 0 blocks
==18654== possibly lost: 0 bytes in 0 blocks
==18654== still reachable: 39,320 bytes in 2,485 blocks
==18654== suppressed: 0 bytes in 0 blocks
==18654== Rerun with --leak-check=full to see details of
leaked memory
==18654==
==18654== For counts of detected and suppressed errors, rerun
with: -v
==18654== Use --track-origins=yes to see where uninitialised
values come from
==18654== ERROR SUMMARY: 349 errors from 6 contexts
(suppressed: 29 from 10)


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

un nombre erreur qui varie du simple au double

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

pouvez vous m aider à comprendre la nature des resultats

sincerement

3 réponses

Avatar
Antoine Leca
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
: 73== 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 à
: 73== 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
Avatar
fakessh
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
: 73== 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 à
: 73== 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
Avatar
fakessh
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
: 73== 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 à
: 73== 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:
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:
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