memory check of /snes/example/tutorials/ex29.c
(Rebecca) Xuefei YUAN
xy2102 at columbia.edu
Mon Jul 27 17:08:09 CDT 2009
Dear Barry,
Do you mean that this small memory leak has been fixed in the current
petsc-3.0.0-p7? 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
More information about the petsc-users
mailing list