I was using valgrind on an application code and in passing I checked the valgrind output for example 4 (see below). I'm not losing any sleep over 36 bytes, but I was just wondering if this (PETSc related?) leak has always been there or if perhaps it is due to some recent change in the library? (I'm using the SVN head with Petsc 3.0.0)
Best, Dave ==3318== 156 (36 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 1 of 5 ==3318== at 0x4026FDE: malloc (vg_replace_malloc.c:207) ==3318== by 0x7BC3548: (within /lib/tls/i686/cmov/libc-2.9.so) ==3318== by 0x7BC3E25: __nss_database_lookup (in /lib/tls/i686/cmov/libc-2.9.so) ==3318== by 0x7C99F5B: ??? ==3318== by 0x7C9C00C: ??? ==3318== by 0x7B69A51: getpwuid_r (in /lib/tls/i686/cmov/libc-2.9.so) ==3318== by 0x7B693C6: getpwuid (in /lib/tls/i686/cmov/libc-2.9.so) ==3318== by 0x6ADF9E1: PetscGetUserName (fuser.c:68) ==3318== by 0x6AC8231: PetscErrorPrintfInitialize (errtrace.c:68) ==3318== by 0x6B1FAB2: PetscInitialize (pinit.c:521) ==3318== by 0x5DE11B7: SlepcInitialize (slepcinit.c:140) ==3318== by 0x48C07B1: libMesh::_init(int&, char**&, int) (libmesh.C:186) ==3318== ==3318== LEAK SUMMARY: ==3318== definitely lost: 36 bytes in 1 blocks. ==3318== indirectly lost: 120 bytes in 10 blocks. ==3318== possibly lost: 0 bytes in 0 blocks. ==3318== still reachable: 122,880 bytes in 6 blocks. ==3318== suppressed: 0 bytes in 0 blocks. ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
