From pedro.lageira at inov.pt Thu Jan 25 17:24:29 2007 From: pedro.lageira at inov.pt (Pedro Lageira) Date: Thu, 25 Jan 2007 16:24:29 +0000 Subject: Valgrind reports memory leaks Message-ID: <45B8D9BD.EE6194F8@inov.pt> Hi, I'm using gcrypt library version 1.2.3. I made a very simple test program and run the Valgrind Memcheck (memory error detector) over it. It seems that gcry_ac_key_pair_generate() has a memory leak... I'm doing something wrong in my code? Can you help me? I'm sending the code and Valgrind output in attach. Thanks, Pedro Lageira -------------- next part -------------- #include #include "gcrypt.h" #define KEYLEN 512 // bits int main() { gcry_error_t err; gcry_ac_handle_t handle; gcry_ac_key_spec_rsa_t rsa_spec; gcry_ac_key_pair_t key_pair; gcry_check_version(NULL); gcry_control(GCRYCTL_DISABLE_SECMEM, 0); gcry_control(GCRYCTL_INITIALIZATION_FINISHED, 0); err = gcry_ac_open(&handle, GCRY_AC_RSA, 0); if (err) { printf("gcry_ac_open() error"); return err; } rsa_spec.e = gcry_mpi_new(0); gcry_mpi_set_ui(rsa_spec.e, 0); err = gcry_ac_key_pair_generate(handle, KEYLEN, &rsa_spec, &key_pair, NULL); gcry_mpi_release(rsa_spec.e); gcry_ac_key_pair_destroy(key_pair); gcry_ac_close(handle); if (err) { printf("gcry_ac_key_pair_generate() error"); return err; } printf("end\n"); return 0; } -------------- next part -------------- ==6884== Memcheck, a memory error detector. ==6884== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==6884== Using LibVEX rev 1658, a library for dynamic binary translation. ==6884== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==6884== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation framework. ==6884== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==6884== For more details, rerun with: -v ==6884== ==6884== My PID = 6884, parent PID = 5456. Prog and args are: ==6884== ./rsa-test ==6884== --6884-- DWARF2 CFI reader: unhandled CFI instruction 0:50 --6884-- DWARF2 CFI reader: unhandled CFI instruction 0:50 ==6884== Conditional jump or move depends on uninitialised value(s) ==6884== at 0x4109B6E: (within /emul/ia32-linux/lib/ld-2.3.6.so) ==6884== by 0x4103687: (within /emul/ia32-linux/lib/ld-2.3.6.so) ==6884== by 0x4110535: (within /emul/ia32-linux/lib/ld-2.3.6.so) ==6884== by 0x4100B2D: (within /emul/ia32-linux/lib/ld-2.3.6.so) ==6884== by 0x41007B6: (within /emul/ia32-linux/lib/ld-2.3.6.so) ==6884== ==6884== Conditional jump or move depends on uninitialised value(s) ==6884== at 0x4109722: (within /emul/ia32-linux/lib/ld-2.3.6.so) ==6884== by 0x4103687: (within /emul/ia32-linux/lib/ld-2.3.6.so) ==6884== by 0x4110535: (within /emul/ia32-linux/lib/ld-2.3.6.so) ==6884== by 0x4100B2D: (within /emul/ia32-linux/lib/ld-2.3.6.so) ==6884== by 0x41007B6: (within /emul/ia32-linux/lib/ld-2.3.6.so) ==6884== ==6884== Conditional jump or move depends on uninitialised value(s) ==6884== at 0x410A026: (within /emul/ia32-linux/lib/ld-2.3.6.so) ==6884== by 0x4103687: (within /emul/ia32-linux/lib/ld-2.3.6.so) ==6884== by 0x4110535: (within /emul/ia32-linux/lib/ld-2.3.6.so) ==6884== by 0x4100B2D: (within /emul/ia32-linux/lib/ld-2.3.6.so) ==6884== by 0x41007B6: (within /emul/ia32-linux/lib/ld-2.3.6.so) ==6884== ==6884== Conditional jump or move depends on uninitialised value(s) ==6884== at 0x41095D5: (within /emul/ia32-linux/lib/ld-2.3.6.so) ==6884== by 0x41039B7: (within /emul/ia32-linux/lib/ld-2.3.6.so) ==6884== by 0x4110535: (within /emul/ia32-linux/lib/ld-2.3.6.so) ==6884== by 0x4100B2D: (within /emul/ia32-linux/lib/ld-2.3.6.so) ==6884== by 0x41007B6: (within /emul/ia32-linux/lib/ld-2.3.6.so) ==6884== ==6884== Conditional jump or move depends on uninitialised value(s) ==6884== at 0x41095DD: (within /emul/ia32-linux/lib/ld-2.3.6.so) ==6884== by 0x41039B7: (within /emul/ia32-linux/lib/ld-2.3.6.so) ==6884== by 0x4110535: (within /emul/ia32-linux/lib/ld-2.3.6.so) ==6884== by 0x4100B2D: (within /emul/ia32-linux/lib/ld-2.3.6.so) ==6884== by 0x41007B6: (within /emul/ia32-linux/lib/ld-2.3.6.so) ==6884== ==6884== Conditional jump or move depends on uninitialised value(s) ==6884== at 0x4109722: (within /emul/ia32-linux/lib/ld-2.3.6.so) ==6884== by 0x41039B7: (within /emul/ia32-linux/lib/ld-2.3.6.so) ==6884== by 0x4110535: (within /emul/ia32-linux/lib/ld-2.3.6.so) ==6884== by 0x4100B2D: (within /emul/ia32-linux/lib/ld-2.3.6.so) ==6884== by 0x41007B6: (within /emul/ia32-linux/lib/ld-2.3.6.so) ==6884== ==6884== Conditional jump or move depends on uninitialised value(s) ==6884== at 0x442EAAA: do_get_buffer (mpicoder.c:254) ==6884== by 0x442F3AF: gcry_mpi_print (mpicoder.c:488) ==6884== by 0x43FCA77: sexp_sscan (sexp.c:1152) ==6884== by 0x43FD176: gcry_sexp_build_array (sexp.c:1399) ==6884== by 0x4405D8F: gcry_ac_key_pair_generate (gcrypt.h:121) ==6884== by 0x80488AB: main (in /home/pltl/mtm2006/project/demo/rsa-test) ==6884== ==6884== Conditional jump or move depends on uninitialised value(s) ==6884== at 0x442EAAA: do_get_buffer (mpicoder.c:254) ==6884== by 0x442F3AF: gcry_mpi_print (mpicoder.c:488) ==6884== by 0x43FCAE0: sexp_sscan (sexp.c:1174) ==6884== by 0x43FD176: gcry_sexp_build_array (sexp.c:1399) ==6884== by 0x4405D8F: gcry_ac_key_pair_generate (gcrypt.h:121) ==6884== by 0x80488AB: main (in /home/pltl/mtm2006/project/demo/rsa-test) ==6884== ==6884== ERROR SUMMARY: 23 errors from 8 contexts (suppressed: 0 from 0) ==6884== malloc/free: in use at exit: 3,121 bytes in 47 blocks. ==6884== malloc/free: 5,014 allocs, 4,967 frees, 129,238 bytes allocated. ==6884== For counts of detected errors, rerun with: -v ==6884== searching for pointers to 47 not-freed blocks. ==6884== checked 123,068 bytes. ==6884== ==6884== ==6884== 16 bytes in 8 blocks are indirectly lost in loss record 1 of 4 ==6884== at 0x43D2367: malloc (vg_replace_malloc.c:149) ==6884== by 0x43FD958: _gcry_private_malloc (stdmem.c:78) ==6884== by 0x43FABB2: _gcry_malloc (global.c:421) ==6884== by 0x43FAC28: gcry_malloc (global.c:441) ==6884== by 0x4404D6F: gcry_ac_data_extract (ac.c:301) ==6884== by 0x4405E4B: gcry_ac_key_pair_generate (ac.c:979) ==6884== by 0x80488AB: main (in /home/pltl/mtm2006/project/demo/rsa-test) ==6884== ==6884== ==6884== 541 (525 direct, 16 indirect) bytes in 6 blocks are definitely lost in loss record 2 of 4 ==6884== at 0x43D2367: malloc (vg_replace_malloc.c:149) ==6884== by 0x43FD958: _gcry_private_malloc (stdmem.c:78) ==6884== by 0x43FABB2: _gcry_malloc (global.c:421) ==6884== by 0x43FAC28: gcry_malloc (global.c:441) ==6884== by 0x4405BC8: gcry_ac_key_pair_generate (ac.c:896) ==6884== by 0x80488AB: main (in /home/pltl/mtm2006/project/demo/rsa-test) ==6884== ==6884== ==6884== 556 bytes in 2 blocks are definitely lost in loss record 3 of 4 ==6884== at 0x43D2462: realloc (vg_replace_malloc.c:306) ==6884== by 0x43FDBEF: _gcry_private_realloc (stdmem.c:146) ==6884== by 0x43FAD29: gcry_realloc (global.c:486) ==6884== by 0x43FAFA9: gcry_xrealloc (global.c:591) ==6884== by 0x43FC093: make_space (sexp.c:794) ==6884== by 0x43FCBD3: sexp_sscan (sexp.c:1187) ==6884== by 0x43FD176: gcry_sexp_build_array (sexp.c:1399) ==6884== by 0x4405D8F: gcry_ac_key_pair_generate (gcrypt.h:121) ==6884== by 0x80488AB: main (in /home/pltl/mtm2006/project/demo/rsa-test) ==6884== ==6884== ==6884== 2,024 bytes in 31 blocks are still reachable in loss record 4 of 4 ==6884== at 0x43D2367: malloc (vg_replace_malloc.c:149) ==6884== by 0x43FD958: _gcry_private_malloc (stdmem.c:78) ==6884== by 0x43FABB2: _gcry_malloc (global.c:421) ==6884== by 0x43FAC28: gcry_malloc (global.c:441) ==6884== by 0x43FE666: _gcry_module_add (module.c:77) ==6884== by 0x43FF037: gcry_cipher_register_default (cipher.c:181) ==6884== by 0x4400A74: _gcry_cipher_init (cipher.c:1376) ==6884== by 0x43FA5ED: global_init (global.c:70) ==6884== by 0x43FA6F2: gcry_check_version (global.c:133) ==6884== by 0x804884E: main (in /home/pltl/mtm2006/project/demo/rsa-test) ==6884== ==6884== LEAK SUMMARY: ==6884== definitely lost: 1,081 bytes in 8 blocks. ==6884== indirectly lost: 16 bytes in 8 blocks. ==6884== possibly lost: 0 bytes in 0 blocks. ==6884== still reachable: 2,024 bytes in 31 blocks. ==6884== suppressed: 0 bytes in 0 blocks. From bradh at frogmouth.net Fri Jan 26 02:21:50 2007 From: bradh at frogmouth.net (Brad Hards) Date: Fri, 26 Jan 2007 12:21:50 +1100 Subject: Valgrind reports memory leaks In-Reply-To: <45B8D9BD.EE6194F8@inov.pt> References: <45B8D9BD.EE6194F8@inov.pt> Message-ID: <200701261221.53676.bradh@frogmouth.net> On Friday 26 January 2007 03:24, Pedro Lageira wrote: > Hi, > > I'm using gcrypt library version 1.2.3. I made a very simple test > program and run the Valgrind Memcheck (memory error detector) over it. > It seems that gcry_ac_key_pair_generate() has a memory leak... > I'm doing something wrong in my code? Can you help me? It does appear to leak for me too. I'm using subversion (and the trace looks slightly different, but it is pointing to the same places). I see: ==5740== 108 bytes in 1 blocks are definitely lost in loss record 2 of 4 ==5740== at 0x4005400: malloc (vg_replace_malloc.c:149) ==5740== by 0x402AEFF: _gcry_private_malloc (stdmem.c:106) ==5740== by 0x4027A67: _gcry_malloc (global.c:478) ==5740== by 0x4027C92: gcry_malloc (global.c:500) ==5740== by 0x402A6B2: gcry_sexp_find_token (sexp.c:420) ==5740== by 0x4036731: _gcry_ac_key_pair_generate (ac.c:1734) ==5740== by 0x40368A8: gcry_ac_key_pair_generate (ac.c:1781) ==5740== by 0x804875E: main (in /home/bradh/junkcode/rsa-test/rsa-test) ==5740== ==5740== ==5740== 144 (128 direct, 16 indirect) bytes in 2 blocks are definitely lost in loss record 3 of 4 ==5740== at 0x40054FB: realloc (vg_replace_malloc.c:306) ==5740== by 0x402AFCA: _gcry_private_realloc (stdmem.c:174) ==5740== by 0x40278ED: gcry_realloc (global.c:545) ==5740== by 0x4035045: _gcry_ac_data_set (ac.c:364) ==5740== by 0x4035A9D: ac_data_extract (ac.c:1311) ==5740== by 0x4036702: _gcry_ac_key_pair_generate (ac.c:1728) ==5740== by 0x40368A8: gcry_ac_key_pair_generate (ac.c:1781) ==5740== by 0x804875E: main (in /home/bradh/junkcode/rsa-test/rsa-test) sexp.c:420 is: newlist = gcry_malloc ( sizeof *newlist + n ); and the newlist never gets free'd. ac.c:364 is: ac_mpis = gcry_realloc (data->data, sizeof (*data->data) * (data->data_n +1)); and, again, no free that I can see. The inside of the sexp code is a bit hairy for me, but if you don't try to disable secure memory, you may see the memory leak indications go away - they did for me. Brad From pedro.lageira at inov.pt Fri Jan 26 12:30:49 2007 From: pedro.lageira at inov.pt (Pedro Lageira) Date: Fri, 26 Jan 2007 11:30:49 +0000 Subject: Valgrind reports memory leaks Message-ID: <45B9E669.99E72E94@inov.pt> Hi Brad Hards, thanks for your help. I have replaced the line: gcry_control(GCRYCTL_DISABLE_SECMEM, 0); with the line: gcry_control(GCRYCTL_INIT_SECMEM, 1); But Valgrind still reports a memory leak: 591 bytes definitely lost (instead of 1,081 bytes). I'm sending the end of the Valgrind output in attach. Thanks, Pedro Lageira -------------- next part -------------- ==9907== ERROR SUMMARY: 23 errors from 8 contexts (suppressed: 0 from 0) ==9907== malloc/free: in use at exit: 2,631 bytes in 46 blocks. ==9907== malloc/free: 3,680 allocs, 3,634 frees, 80,420 bytes allocated. ==9907== For counts of detected errors, rerun with: -v ==9907== searching for pointers to 46 not-freed blocks. ==9907== checked 139,452 bytes. ==9907== ==9907== ==9907== 16 bytes in 8 blocks are indirectly lost in loss record 1 of 4 ==9907== at 0x43D2367: malloc (vg_replace_malloc.c:149) ==9907== by 0x43FD958: _gcry_private_malloc (stdmem.c:78) ==9907== by 0x43FABB2: _gcry_malloc (global.c:421) ==9907== by 0x43FAC28: gcry_malloc (global.c:441) ==9907== by 0x4404D6F: gcry_ac_data_extract (ac.c:301) ==9907== by 0x4405E4B: gcry_ac_key_pair_generate (ac.c:979) ==9907== by 0x80488AB: main (in /home/pltl/mtm2006/project/demo/rsa-test) ==9907== ==9907== ==9907== 65 bytes in 1 blocks are definitely lost in loss record 2 of 4 ==9907== at 0x43D2462: realloc (vg_replace_malloc.c:306) ==9907== by 0x43FDBEF: _gcry_private_realloc (stdmem.c:146) ==9907== by 0x43FAD29: gcry_realloc (global.c:486) ==9907== by 0x43FAFA9: gcry_xrealloc (global.c:591) ==9907== by 0x43FC093: make_space (sexp.c:794) ==9907== by 0x43FCBD3: sexp_sscan (sexp.c:1187) ==9907== by 0x43FD176: gcry_sexp_build_array (sexp.c:1399) ==9907== by 0x4405D8F: gcry_ac_key_pair_generate (gcrypt.h:121) ==9907== by 0x80488AB: main (in /home/pltl/mtm2006/project/demo/rsa-test) ==9907== ==9907== ==9907== 542 (526 direct, 16 indirect) bytes in 6 blocks are definitely lost in loss record 3 of 4 ==9907== at 0x43D2367: malloc (vg_replace_malloc.c:149) ==9907== by 0x43FD958: _gcry_private_malloc (stdmem.c:78) ==9907== by 0x43FABB2: _gcry_malloc (global.c:421) ==9907== by 0x43FAC28: gcry_malloc (global.c:441) ==9907== by 0x4405BC8: gcry_ac_key_pair_generate (ac.c:896) ==9907== by 0x80488AB: main (in /home/pltl/mtm2006/project/demo/rsa-test) ==9907== ==9907== ==9907== 2,024 bytes in 31 blocks are still reachable in loss record 4 of 4 ==9907== at 0x43D2367: malloc (vg_replace_malloc.c:149) ==9907== by 0x43FD958: _gcry_private_malloc (stdmem.c:78) ==9907== by 0x43FABB2: _gcry_malloc (global.c:421) ==9907== by 0x43FAC28: gcry_malloc (global.c:441) ==9907== by 0x43FE666: _gcry_module_add (module.c:77) ==9907== by 0x43FF037: gcry_cipher_register_default (cipher.c:181) ==9907== by 0x4400A74: _gcry_cipher_init (cipher.c:1376) ==9907== by 0x43FA5ED: global_init (global.c:70) ==9907== by 0x43FA6F2: gcry_check_version (global.c:133) ==9907== by 0x804884E: main (in /home/pltl/mtm2006/project/demo/rsa-test) ==9907== ==9907== LEAK SUMMARY: ==9907== definitely lost: 591 bytes in 7 blocks. ==9907== indirectly lost: 16 bytes in 8 blocks. ==9907== possibly lost: 0 bytes in 0 blocks. ==9907== still reachable: 2,024 bytes in 31 blocks. ==9907== suppressed: 0 bytes in 0 blocks. From wk at gnupg.org Fri Jan 26 19:30:10 2007 From: wk at gnupg.org (Werner Koch) Date: Fri, 26 Jan 2007 19:30:10 +0100 Subject: Valgrind reports memory leaks In-Reply-To: <45B8D9BD.EE6194F8@inov.pt> (Pedro Lageira's message of "Thu\, 25 Jan 2007 16\:24\:29 +0000") References: <45B8D9BD.EE6194F8@inov.pt> Message-ID: <87sldxhc99.fsf@wheatstone.g10code.de> On Thu, 25 Jan 2007 17:24, pedro.lageira at inov.pt said: > I'm using gcrypt library version 1.2.3. I made a very simple test > program and run the Valgrind Memcheck (memory error detector) over it. > It seems that gcry_ac_key_pair_generate() has a memory leak... > I'm doing something wrong in my code? Can you help me? We know that the ac family of functions have a couple of memory leaks. Some have been fixed in the developer version but not all. It is not really simple. I suggest to avoid the ac functions and better use the pk functions - they are activly used by GnuPG and more matured. Salam-Shalom, Werner From bradh at frogmouth.net Fri Jan 26 23:11:49 2007 From: bradh at frogmouth.net (Brad Hards) Date: Sat, 27 Jan 2007 09:11:49 +1100 Subject: Valgrind reports memory leaks In-Reply-To: <45B9E669.99E72E94@inov.pt> References: <45B9E669.99E72E94@inov.pt> Message-ID: <200701270911.50721.bradh@frogmouth.net> On Friday 26 January 2007 22:30, Pedro Lageira wrote: > Hi Brad Hards, > > thanks for your help. I have replaced the line: > gcry_control(GCRYCTL_DISABLE_SECMEM, 0); > with the line: > gcry_control(GCRYCTL_INIT_SECMEM, 1); > > But Valgrind still reports a memory leak: > 591 bytes definitely lost (instead of 1,081 bytes). > I'm sending the end of the Valgrind output in attach. This is probably a difference between the version you are using (1.2.3) and the version that I am using (most recent svn trunk from yesterday). As Werner pointed out, some leaks are known, and some have been fixed. Brad