memory leak from valgrind on ex1

[Matthew Knepley]

On Sun, Aug 9, 2009 at 9:09 AM, Umut Tabak <u.tabak at tudelft.nl> wrote:

> Matthew Knepley wrote:
>
>> There are some strings which might not get freed, but they are very small.
>> How big are we talking?
>>
>>   Matt
>>
>>  Hi, Thanks for the quick return on Sunday,
>
> Here is the result of ex1.c that is mentioned in the previous mail, they
> are small indeed, but I was wondering if there were still things I could not
> manage with my pointer allocations/assignments, that is the reason why I
> made a post.


These are just the names of some classes which do nto get freed on exit.

   Matt


>
> I also attached another valgrind output, This was just to be sure that I am
> coding without leaks. BTW, the program seems to work but there are other
> problems related to eigenvalues I would like to solve for the moment...
>
> Best regards,
> Umut
>
> ==23836== Memcheck, a memory error detector.
> ==23836== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
> ==23836== Using LibVEX rev 1884, a library for dynamic binary translation.
> ==23836== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
> ==23836== Using valgrind-3.4.1-Debian, a dynamic binary instrumentation
> framework.
> ==23836== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
> ==23836== For more details, rerun with: -v
> ==23836==
> KSP Object:
>  type: gmres
>   GMRES: restart=30, using Classical (unmodified) Gram-Schmidt
> Orthogonalization with no iterative refinement
>   GMRES: happy breakdown tolerance 1e-30
>  maximum iterations=10000, initial guess is zero
>  tolerances:  relative=1e-07, absolute=1e-50, divergence=10000
>  left preconditioning
> PC Object:
>  type: jacobi
>  linear system matrix = precond matrix:
>  Matrix Object:
>   type=seqaij, rows=10, cols=10
>   total: nonzeros=28, allocated nonzeros=50
>     not using I-node routines
> Norm of error < 1.e-12, Iterations 5
> ==23836==
> ==23836== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 26 from 3)
> ==23836== malloc/free: in use at exit: 292 bytes in 11 blocks.
> ==23836== malloc/free: 1,011 allocs, 1,000 frees, 974,088 bytes allocated.
> ==23836== For counts of detected errors, rerun with: -v
> ==23836== searching for pointers to 11 not-freed blocks.
> ==23836== checked 1,678,608 bytes.
> ==23836==
> ==23836== 292 (52 direct, 240 indirect) bytes in 1 blocks are definitely
> lost in loss record 1 of 3
> ==23836==    at 0x4C278AE: malloc (vg_replace_malloc.c:207)
> ==23836==    by 0x82D410A: (within /lib/libc-2.9.so)
> ==23836==    by 0x82D4A06: __nss_database_lookup (in /lib/libc-2.9.so)
> ==23836==    by 0x918033F: ???
> ==23836==    by 0x9182264: ???
> ==23836==    by 0x8282051: getpwuid_r (in /lib/libc-2.9.so)
> ==23836==    by 0x828191E: getpwuid (in /lib/libc-2.9.so)
> ==23836==    by 0x640685B: PetscGetUserName(char*, unsigned long)
> (fuser.c:68)
> ==23836==    by 0x63ED66E: PetscErrorPrintfInitialize() (errtrace.c:68)
> ==23836==    by 0x644A995: PetscInitialize(int*, char***, char const*, char
> const*) (pinit.c:521)
> ==23836==    by 0x401645: main (ex1.c:37)
> ==23836==
> ==23836== LEAK SUMMARY:
> ==23836==    definitely lost: 52 bytes in 1 blocks.
> ==23836==    indirectly lost: 240 bytes in 10 blocks.
> ==23836==      possibly lost: 0 bytes in 0 blocks.
> ==23836==    still reachable: 0 bytes in 0 blocks.
> ==23836==         suppressed: 0 bytes in 0 blocks.
>
>
>


-- 
What most experimenters take for granted before they begin their experiments
is infinitely more interesting than any results to which their experiments
lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20090809/7fe0971b/attachment.htm>