memory leak from valgrind on ex1

[Umut Tabak]

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.

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: petscVg.dat
Type: application/x-ns-proxy-autoconfig
Size: 10488 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20090809/7e44bc42/attachment.pac>