On Mon, Jul 27, 2009 at 4:34 PM, (Rebecca) Xuefei YUAN <span dir="ltr"><<a href="mailto:xy2102@columbia.edu">xy2102@columbia.edu</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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?</blockquote><div><br>Not from what you mailed in. On that DA line, I see PetscHeaderCreate(). Is that what you see?<br>
<br> Matt<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Thanks,<br>
<br>
R<div><div></div><div class="h5"><br>
<br>
Quoting Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>>:<br>
<br>
</div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="h5">
On Mon, Jul 27, 2009 at 3:51 PM, (Rebecca) Xuefei YUAN<br>
<<a href="mailto:xy2102@columbia.edu" target="_blank">xy2102@columbia.edu</a>>wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br>
<br>
My own code has some left bytes still reachable according to valgrind, then<br>
I use two different version petsc (2.3.3-p15 and 3.0.0-p1) to compile and<br>
make the files, it gives me different number of bytes left still reachable.<br>
Moreover, I picked up the /snes/example/tutorials/ex29.c as another example,<br>
and found that some bytes are still reachable, what is the cause of it? It<br>
shows that it is from DACreate2D() and the I use -malloc_dump to get those<br>
unfreed informations.<br>
<br>
I understand that for those 5 loss record, the 2nd, 3rd and 4th are true<br>
for all examples, but where do 1st and 5th ones come from? Also, the<br>
-malloc_dump information shows that there are<br>
"[0]Total space allocated 37780 bytes",<br>
but valgrind gives the information as<br>
"==26628== still reachable: 132,828 bytes in 323 blocks"<br>
<br>
Why there is a big difference?<br>
</blockquote>
<br>
<br>
1 is fine. It is from PMPI setup, which has some bytes not freed from<br>
setting up the MPI<br>
processes. The last one looks like an unfreed header for a DA, which is<br>
strange.<br>
<br>
Matt<br>
<br>
<br>
</div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="h5">
<br>
Thanks very much!<br>
<br>
Rebecca<br>
<br>
Here is the message from valgrind of running ex29:<br>
==26628== 32 bytes in 2 blocks are still reachable in loss record 1 of 5<br>
==26628== at 0x4022AB8: malloc (vg_replace_malloc.c:207)<br>
==26628== by 0x86F9A78: MPID_VCRT_Create (mpid_vc.c:62)<br>
==26628== by 0x86F743A: MPID_Init (mpid_init.c:116)<br>
==26628== by 0x86D040B: MPIR_Init_thread (initthread.c:288)<br>
==26628== by 0x86CFF2D: PMPI_Init (init.c:106)<br>
==26628== by 0x8613D69: PetscInitialize (pinit.c:503)<br>
==26628== by 0x804B796: main (ex29.c:139)<br>
==26628==<br>
==26628==<br>
==26628== 156 (36 direct, 120 indirect) bytes in 1 blocks are definitely<br>
lost in loss record 2 of 5<br>
==26628== at 0x4022AB8: malloc (vg_replace_malloc.c:207)<br>
==26628== by 0x429B3E2: (within /lib/tls/i686/cmov/<a href="http://libc-2.7.so" target="_blank">libc-2.7.so</a>)<br>
==26628== by 0x429BC2D: __nss_database_lookup (in /lib/tls/i686/cmov/<br>
<a href="http://libc-2.7.so" target="_blank">libc-2.7.so</a>)<br>
==26628== by 0x4732FDB: ???<br>
==26628== by 0x473413C: ???<br>
==26628== by 0x4247D15: getpwuid_r (in /lib/tls/i686/cmov/<a href="http://libc-2.7.so" target="_blank">libc-2.7.so</a>)<br>
==26628== by 0x424765D: getpwuid (in /lib/tls/i686/cmov/<a href="http://libc-2.7.so" target="_blank">libc-2.7.so</a>)<br>
==26628== by 0x8623509: PetscGetUserName (fuser.c:68)<br>
==26628== by 0x85E0CF0: PetscErrorPrintfInitialize (errtrace.c:68)<br>
==26628== by 0x8613E23: PetscInitialize (pinit.c:518)<br>
==26628== by 0x804B796: main (ex29.c:139)<br>
==26628==<br>
==26628==<br>
==26628== 40 bytes in 5 blocks are indirectly lost in loss record 3 of 5<br>
==26628== at 0x4022AB8: malloc (vg_replace_malloc.c:207)<br>
==26628== by 0x429AFBB: __nss_lookup_function (in /lib/tls/i686/cmov/<br>
<a href="http://libc-2.7.so" target="_blank">libc-2.7.so</a>)<br>
==26628== by 0x4732FFB: ???<br>
==26628== by 0x473413C: ???<br>
==26628== by 0x4247D15: getpwuid_r (in /lib/tls/i686/cmov/<a href="http://libc-2.7.so" target="_blank">libc-2.7.so</a>)<br>
==26628== by 0x424765D: getpwuid (in /lib/tls/i686/cmov/<a href="http://libc-2.7.so" target="_blank">libc-2.7.so</a>)<br>
==26628== by 0x8623509: PetscGetUserName (fuser.c:68)<br>
==26628== by 0x85E0CF0: PetscErrorPrintfInitialize (errtrace.c:68)<br>
==26628== by 0x8613E23: PetscInitialize (pinit.c:518)<br>
==26628== by 0x804B796: main (ex29.c:139)<br>
==26628==<br>
==26628==<br>
==26628== 80 bytes in 5 blocks are indirectly lost in loss record 4 of 5<br>
==26628== at 0x4022AB8: malloc (vg_replace_malloc.c:207)<br>
==26628== by 0x428839B: tsearch (in /lib/tls/i686/cmov/<a href="http://libc-2.7.so" target="_blank">libc-2.7.so</a>)<br>
==26628== by 0x429AF7D: __nss_lookup_function (in /lib/tls/i686/cmov/<br>
<a href="http://libc-2.7.so" target="_blank">libc-2.7.so</a>)<br>
==26628== by 0x4732FFB: ???<br>
==26628== by 0x473413C: ???<br>
==26628== by 0x4247D15: getpwuid_r (in /lib/tls/i686/cmov/<a href="http://libc-2.7.so" target="_blank">libc-2.7.so</a>)<br>
==26628== by 0x424765D: getpwuid (in /lib/tls/i686/cmov/<a href="http://libc-2.7.so" target="_blank">libc-2.7.so</a>)<br>
==26628== by 0x8623509: PetscGetUserName (fuser.c:68)<br>
==26628== by 0x85E0CF0: PetscErrorPrintfInitialize (errtrace.c:68)<br>
==26628== by 0x8613E23: PetscInitialize (pinit.c:518)<br>
==26628== by 0x804B796: main (ex29.c:139)<br>
==26628==<br>
==26628==<br>
==26628== 132,796 bytes in 321 blocks are still reachable in loss record 5<br>
of 5<br>
==26628== at 0x4022AB8: malloc (vg_replace_malloc.c:207)<br>
==26628== by 0x85EF3AC: PetscMallocAlign (mal.c:40)<br>
==26628== by 0x85F049B: PetscTrMallocDefault (mtr.c:194)<br>
==26628== by 0x81BCD3F: DACreate2d (da2.c:364)<br>
==26628== by 0x804BAFB: main (ex29.c:153)<br>
==26628==<br>
==26628== LEAK SUMMARY:<br>
==26628== definitely lost: 36 bytes in 1 blocks.<br>
==26628== indirectly lost: 120 bytes in 10 blocks.<br>
==26628== possibly lost: 0 bytes in 0 blocks.<br>
==26628== still reachable: 132,828 bytes in 323 blocks.<br>
==26628== suppressed: 0 bytes in 0 blocks.<br>
<br>
<br>
--<br>
(Rebecca) Xuefei YUAN<br>
Department of Applied Physics and Applied Mathematics<br>
Columbia University<br>
Tel:917-399-8032<br>
</div></div><a href="http://www.columbia.edu/%7Exy2102" target="_blank">www.columbia.edu/~xy2102</a> <<a href="http://www.columbia.edu/%7Exy2102" target="_blank">http://www.columbia.edu/%7Exy2102</a>><br>
<br>
<br>
</blockquote>
<br>
<br>
--<div class="im"><br>
What most experimenters take for granted before they begin their experiments<br>
is infinitely more interesting than any results to which their experiments<br>
lead.<br>
-- Norbert Wiener<br>
<br>
</div></blockquote>
<br>
<br><div><div></div><div class="h5">
<br>
-- <br>
(Rebecca) Xuefei YUAN<br>
Department of Applied Physics and Applied Mathematics<br>
Columbia University<br>
Tel:917-399-8032<br>
<a href="http://www.columbia.edu/%7Exy2102" target="_blank">www.columbia.edu/~xy2102</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener<br>