memory check of /snes/example/tutorials/ex29.c

Mon Jul 27 16:53:20 CDT 2009

   This was due to a small memory leak in DMMGSetNullSpace() of the  
vectors creating internally to hold the null space. I have pushed a  
fix to petsc-3.0.0 and petsc-dev
It will be fixed in the next 3.0.0 patch.

    Note this would not cause the "out of memory" for runs at bigger  
grid sizes. That is likely just coming from trying to run too large a  
problem for your memory size.

    Thanks for reporting the memory leak,

    Barry

On Jul 27, 2009, at 4:34 PM, (Rebecca) Xuefei YUAN wrote:

> Those unfreed bytes cause "out of memory" when it runs at bigger  
> grid sizes. So I have to find out those unfreed memory and free  
> them... Any suggestions?
>
> Thanks,
>
> R
>
> Quoting Matthew Knepley <knepley at gmail.com>:
>
>> On Mon, Jul 27, 2009 at 3:51 PM, (Rebecca) Xuefei YUAN
>> <xy2102 at columbia.edu>wrote:
>>
>>> Hi,
>>>
>>> My own code has some left bytes still reachable according to  
>>> valgrind, then
>>> I use two different version petsc (2.3.3-p15 and 3.0.0-p1) to  
>>> compile and
>>> make the files, it gives me different number of bytes left still  
>>> reachable.
>>> Moreover, I picked up the /snes/example/tutorials/ex29.c as  
>>> another example,
>>> and found that some bytes are still reachable, what is the cause  
>>> of it? It
>>> shows that it is from DACreate2D() and the I use -malloc_dump to  
>>> get those
>>> unfreed informations.
>>>
>>> I understand that for those 5 loss record, the 2nd, 3rd and 4th  
>>> are true
>>> for all examples, but where do 1st and 5th ones come from? Also, the
>>> -malloc_dump information shows that there are
>>> "[0]Total space allocated 37780 bytes",
>>> but valgrind gives the information as
>>> "==26628==    still reachable: 132,828 bytes in 323 blocks"
>>>
>>> Why there is a big difference?
>>
>>
>> 1 is fine. It is from PMPI setup, which has some bytes not freed from
>> setting up the MPI
>> processes. The last one looks like an unfreed header for a DA,  
>> which is
>> strange.
>>
>>  Matt
>>
>>
>>>
>>> Thanks very much!
>>>
>>> Rebecca
>>>
>>> Here is the message from valgrind of running ex29:
>>> ==26628== 32 bytes in 2 blocks are still reachable in loss record  
>>> 1 of 5
>>> ==26628==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
>>> ==26628==    by 0x86F9A78: MPID_VCRT_Create (mpid_vc.c:62)
>>> ==26628==    by 0x86F743A: MPID_Init (mpid_init.c:116)
>>> ==26628==    by 0x86D040B: MPIR_Init_thread (initthread.c:288)
>>> ==26628==    by 0x86CFF2D: PMPI_Init (init.c:106)
>>> ==26628==    by 0x8613D69: PetscInitialize (pinit.c:503)
>>> ==26628==    by 0x804B796: main (ex29.c:139)
>>> ==26628==
>>> ==26628==
>>> ==26628== 156 (36 direct, 120 indirect) bytes in 1 blocks are  
>>> definitely
>>> lost in loss record 2 of 5
>>> ==26628==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
>>> ==26628==    by 0x429B3E2: (within /lib/tls/i686/cmov/libc-2.7.so)
>>> ==26628==    by 0x429BC2D: __nss_database_lookup (in /lib/tls/i686/ 
>>> cmov/
>>> libc-2.7.so)
>>> ==26628==    by 0x4732FDB: ???
>>> ==26628==    by 0x473413C: ???
>>> ==26628==    by 0x4247D15: getpwuid_r (in /lib/tls/i686/cmov/ 
>>> libc-2.7.so)
>>> ==26628==    by 0x424765D: getpwuid (in /lib/tls/i686/cmov/ 
>>> libc-2.7.so)
>>> ==26628==    by 0x8623509: PetscGetUserName (fuser.c:68)
>>> ==26628==    by 0x85E0CF0: PetscErrorPrintfInitialize (errtrace.c: 
>>> 68)
>>> ==26628==    by 0x8613E23: PetscInitialize (pinit.c:518)
>>> ==26628==    by 0x804B796: main (ex29.c:139)
>>> ==26628==
>>> ==26628==
>>> ==26628== 40 bytes in 5 blocks are indirectly lost in loss record  
>>> 3 of 5
>>> ==26628==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
>>> ==26628==    by 0x429AFBB: __nss_lookup_function (in /lib/tls/i686/ 
>>> cmov/
>>> libc-2.7.so)
>>> ==26628==    by 0x4732FFB: ???
>>> ==26628==    by 0x473413C: ???
>>> ==26628==    by 0x4247D15: getpwuid_r (in /lib/tls/i686/cmov/ 
>>> libc-2.7.so)
>>> ==26628==    by 0x424765D: getpwuid (in /lib/tls/i686/cmov/ 
>>> libc-2.7.so)
>>> ==26628==    by 0x8623509: PetscGetUserName (fuser.c:68)
>>> ==26628==    by 0x85E0CF0: PetscErrorPrintfInitialize (errtrace.c: 
>>> 68)
>>> ==26628==    by 0x8613E23: PetscInitialize (pinit.c:518)
>>> ==26628==    by 0x804B796: main (ex29.c:139)
>>> ==26628==
>>> ==26628==
>>> ==26628== 80 bytes in 5 blocks are indirectly lost in loss record  
>>> 4 of 5
>>> ==26628==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
>>> ==26628==    by 0x428839B: tsearch (in /lib/tls/i686/cmov/ 
>>> libc-2.7.so)
>>> ==26628==    by 0x429AF7D: __nss_lookup_function (in /lib/tls/i686/ 
>>> cmov/
>>> libc-2.7.so)
>>> ==26628==    by 0x4732FFB: ???
>>> ==26628==    by 0x473413C: ???
>>> ==26628==    by 0x4247D15: getpwuid_r (in /lib/tls/i686/cmov/ 
>>> libc-2.7.so)
>>> ==26628==    by 0x424765D: getpwuid (in /lib/tls/i686/cmov/ 
>>> libc-2.7.so)
>>> ==26628==    by 0x8623509: PetscGetUserName (fuser.c:68)
>>> ==26628==    by 0x85E0CF0: PetscErrorPrintfInitialize (errtrace.c: 
>>> 68)
>>> ==26628==    by 0x8613E23: PetscInitialize (pinit.c:518)
>>> ==26628==    by 0x804B796: main (ex29.c:139)
>>> ==26628==
>>> ==26628==
>>> ==26628== 132,796 bytes in 321 blocks are still reachable in loss  
>>> record 5
>>> of 5
>>> ==26628==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
>>> ==26628==    by 0x85EF3AC: PetscMallocAlign (mal.c:40)
>>> ==26628==    by 0x85F049B: PetscTrMallocDefault (mtr.c:194)
>>> ==26628==    by 0x81BCD3F: DACreate2d (da2.c:364)
>>> ==26628==    by 0x804BAFB: main (ex29.c:153)
>>> ==26628==
>>> ==26628== LEAK SUMMARY:
>>> ==26628==    definitely lost: 36 bytes in 1 blocks.
>>> ==26628==    indirectly lost: 120 bytes in 10 blocks.
>>> ==26628==      possibly lost: 0 bytes in 0 blocks.
>>> ==26628==    still reachable: 132,828 bytes in 323 blocks.
>>> ==26628==         suppressed: 0 bytes in 0 blocks.
>>>
>>>
>>> --
>>> (Rebecca) Xuefei YUAN
>>> Department of Applied Physics and Applied Mathematics
>>> Columbia University
>>> Tel:917-399-8032
>>> www.columbia.edu/~xy2102 <http://www.columbia.edu/%7Exy2102>
>>>
>>>
>>
>>
>> --
>> 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
>>
>
>
>
> -- 
> (Rebecca) Xuefei YUAN
> Department of Applied Physics and Applied Mathematics
> Columbia University
> Tel:917-399-8032
> www.columbia.edu/~xy2102
>