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

[Barry Smith]

On Jul 27, 2009, at 5:08 PM, (Rebecca) Xuefei YUAN wrote:

> Dear Barry,
>
> Do you mean that this small memory leak has been fixed in the  
> current petsc-3.0.0-p7?

     No, it is fixed in the Mecurial version and in petsc-dev. It will  
be fixed in the next patch. As I said before it is not a serious  
memory leak.

    Barry

> Since the version I have is petsc-3.0.0-p1.
>
> By the way, have you noticed another email about the possible bug in  
> DMCompositeGetMatrix() function?
>
> Thanks,
>
> Rebecca
>
> Quoting Barry Smith <bsmith at mcs.anl.gov>:
>
>>
>>  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
>>>
>
>
>
> -- 
> (Rebecca) Xuefei YUAN
> Department of Applied Physics and Applied Mathematics
> Columbia University
> Tel:917-399-8032
> www.columbia.edu/~xy2102
>