<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Thank you !</p>
<p>I configured both with the same options, but maybe the default
have changed between versions.</p>
<p>Now I understand. And thank you for the -malloc_dump option, I
forgot about it.</p>
<p><br>
</p>
<p>Pierre<br>
</p>
<br>
<div class="moz-cite-prefix">On 12/10/21 17:16, Barry Smith wrote:<br>
</div>
<blockquote type="cite"
cite="mid:A1CF0903-218C-4F79-A38C-6341DFAB7221@petsc.dev">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div class=""><br class="">
</div>
Notice with your 3.14
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<p class=""><tt class="">8 bytes in 1 blocks are definitely
lost in loss record 2 of 3</tt><br class="">
<tt class="">==5463== at 0x4C2BE2D: memalign
(vg_replace_malloc.c:858)</tt><br class="">
<tt class="">==5463== by 0x5655AEF: PetscMallocAlign
(mal.c:52)</tt><br class="">
<tt class="">==5463== by 0x5657465: PetscMallocA
(mal.c:425)</tt><br class="">
<tt class="">==5463== by 0x4191D3: main (main.c:63)</tt></p>
<div class=""><br class="">
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
but with your 3.15 </div>
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<blockquote type="cite"
cite="mid:1DA582BF-515E-48B2-93DA-5BD1B3B7070D@petsc.dev"
class="">
<div class="">
<div class="">
<blockquote type="cite" class="">
<div class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<blockquote type="cite"
cite="mid:CAMYG4GnECNxUSwDU1zDrRuXP_8rQRdY3a=R7RDDHBWu-nJnA2w@mail.gmail.com"
class="">
<div dir="ltr" class="">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin: 0px 0px 0px 0.8ex;
border-left-width: 1px;
border-left-style: solid;
border-left-color: rgb(204, 204, 204);
padding-left: 1ex;">> ==2036== 1,636
bytes in 1 blocks are still reachable in
loss record 4 <br class="">
> of 4<br class="">
> ==2036== at 0x4C2BE2D: memalign
(vg_replace_malloc.c:858)<br class="">
> ==2036== by 0x54AC0CB:
PetscMallocAlign (mal.c:54)<br class="">
> ==2036== by 0x54AFBA9:
PetscTrMallocDefault (mtr.c:183)<br
class="">
> ==2036== by 0x54ADDD2:
PetscMallocA (mal.c:423)<br class="">
> ==2036== by 0x41A52F: main
(main.c:9)</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">note the </div>
<div class=""><br class="">
</div>
<blockquote type="cite" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<blockquote type="cite"
cite="mid:1DA582BF-515E-48B2-93DA-5BD1B3B7070D@petsc.dev"
class="">
<div class="">
<div class="">
<blockquote type="cite" class="">
<div class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<blockquote type="cite"
cite="mid:CAMYG4GnECNxUSwDU1zDrRuXP_8rQRdY3a=R7RDDHBWu-nJnA2w@mail.gmail.com"
class="">
<div dir="ltr" class="">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin: 0px 0px 0px 0.8ex;
border-left-width: 1px;
border-left-style: solid;
border-left-color: rgb(204, 204, 204);
padding-left: 1ex;">PetscTrMallocDefault</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote>
<div class=""><br class="">
</div>
<br class="">
so with 3.15 it is using the "tracing" version of PETSc malloc
which keeps a list of unfreeded memory but with 3.14 it is not
using the tracing version. This could happen because 3.14 was
configured with --with-debugging=0 while 3.15 was not. Or having
-malloc_debug in the environmental variable PETSC_OPTIONS. But I
don't think it is due to any changes in the PETSc source code.</div>
<div class=""><br class="">
</div>
<div class=""> Barry</div>
<div class=""><br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On Oct 12, 2021, at 11:06 AM, Pierre Seize
<<a href="mailto:Pierre.Seize@onera.fr" class=""
moz-do-not-send="true">Pierre.Seize@onera.fr</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<p class="">With 3.14 : both malloc and PetscMalloc1 are
definitely lost, which is what I want:</p>
<p class=""><tt class="">==5463== Memcheck, a memory
error detector</tt><br class="">
<tt class="">==5463== Copyright (C) 2002-2015, and GNU
GPL'd, by Julian Seward et al.</tt><br class="">
<tt class="">==5463== Using Valgrind-3.12.0 and
LibVEX; rerun with -h for copyright info</tt><br
class="">
<tt class="">==5463== Command: ./build/bin/yanss
data/box.yaml</tt><br class="">
<tt class="">==5463== </tt><br class="">
<tt class="">==5463== </tt><br class="">
<tt class="">==5463== HEAP SUMMARY:</tt><br class="">
<tt class="">==5463== in use at exit: 48 bytes in
3 blocks</tt><br class="">
<tt class="">==5463== total heap usage: 2,092
allocs, 2,089 frees, 9,139,664 bytes allocated</tt><br
class="">
<tt class="">==5463== </tt><br class="">
<tt class="">==5463== 8 bytes in 1 blocks are
definitely lost in loss record 1 of 3</tt><br
class="">
<tt class="">==5463== at 0x4C29BE3: malloc
(vg_replace_malloc.c:299)</tt><br class="">
<tt class="">==5463== by 0x4191A1: main (main.c:62)</tt><br
class="">
<tt class="">==5463== </tt><br class="">
<tt class="">==5463== 8 bytes in 1 blocks are
definitely lost in loss record 2 of 3</tt><br
class="">
<tt class="">==5463== at 0x4C2BE2D: memalign
(vg_replace_malloc.c:858)</tt><br class="">
<tt class="">==5463== by 0x5655AEF:
PetscMallocAlign (mal.c:52)</tt><br class="">
<tt class="">==5463== by 0x5657465: PetscMallocA
(mal.c:425)</tt><br class="">
<tt class="">==5463== by 0x4191D3: main (main.c:63)</tt><br
class="">
<tt class="">==5463== </tt><br class="">
<tt class="">==5463== LEAK SUMMARY:</tt><br class="">
<tt class="">==5463== definitely lost: 16 bytes in
2 blocks</tt><br class="">
<tt class="">==5463== indirectly lost: 0 bytes in 0
blocks</tt><br class="">
<tt class="">==5463== possibly lost: 0 bytes in 0
blocks</tt><br class="">
<tt class="">==5463== still reachable: 32 bytes in
1 blocks</tt><br class="">
<tt class="">==5463== suppressed: 0 bytes in 0
blocks</tt><br class="">
<tt class="">==5463== Reachable blocks (those to which
a pointer was found) are not shown.</tt><br class="">
<tt class="">==5463== To see them, rerun with:
--leak-check=full --show-leak-kinds=all</tt><br
class="">
<tt class="">==5463== </tt><br class="">
<tt class="">==5463== For counts of detected and
suppressed errors, rerun with: -v</tt><br class="">
<tt class="">==5463== ERROR SUMMARY: 2 errors from 2
contexts (suppressed: 0 from 0)</tt><br class="">
</p>
but on a more recent version, the lost memory from
PetscMalloc1 is marked ad reachable. It bothers me as I
use valgrind to make sure I free everything. Usually the
lost memory would be reported right away, but now it
isn't.<br class="">
If I understand Barry's answer, this is because the
memory block is large ("1,636 bytes in 1 blocks") and
valgrind gives up on this block tracing ? Then out of
curiosity, why is this block 8 bytes in 3.14 and 1636
bytes today ?<br class="">
<br class="">
Thank you for your time<br class="">
Pierre<br class="">
<br class="">
<div class="moz-cite-prefix">On 12/10/21 16:51, Barry
Smith wrote:<br class="">
</div>
<blockquote type="cite"
cite="mid:1DA582BF-515E-48B2-93DA-5BD1B3B7070D@petsc.dev"
class="">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252" class="">
<div class=""><br class="">
</div>
Do you have the valgrind output from 3.14 ?
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite"
cite="mid:CAMYG4GnECNxUSwDU1zDrRuXP_8rQRdY3a=R7RDDHBWu-nJnA2w@mail.gmail.com"
style="background-color: rgb(255, 255, 255);"
class="">
<div dir="ltr" class="">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:
0px 0px 0px 0.8ex; border-left-width: 1px;
border-left-style: solid; border-left-color:
rgb(204, 204, 204); padding-left: 1ex;">1,636
bytes in 1 blocks are still reachable in
loss record 4 <br class="">
> of 4<br class="">
> ==2036== at 0x4C2BE2D: memalign
(vg_replace_malloc.c:858)<br class="">
> ==2036== by 0x54AC0CB:
PetscMallocAlign (mal.c:54)<br class="">
> ==2036== by 0x54AFBA9:
PetscTrMallocDefault (mtr.c:183)<br class="">
> ==2036== by 0x54ADDD2: PetscMallocA
(mal.c:423)<br class="">
> ==2036== by 0x41A52F: main
(main.c:9)<br class="">
> ==2036==</blockquote>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
Given the large amount of memory in the block I
think tracing of PETSc's memory allocation is turned
on with this run, this may mean the memory is
reachable but with your 3.14 run I would guess the
memory size is 8 bytes and tracing is not turned on
so the memory is listed as "lost". But I do not
understand the subtleties of reachable.</div>
<div class=""><br class="">
</div>
<div class="">Barry</div>
<div class=""><br class="">
</div>
<div class=""> <br class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On Oct 12, 2021, at 10:38 AM,
Pierre Seize <<a
href="mailto:Pierre.Seize@onera.fr" class=""
moz-do-not-send="true">Pierre.Seize@onera.fr</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252"
class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<p class="">The "bug" is that memory from
PetscMalloc1 that is not freed is reported
as "definitely lost" in v3.14 (OK) but as
"still reachable" in today's release (not
OK).</p>
<p class="">Here I forget to free the memory
on purpose, I would like valgrind to
report it's lost and not still reachable.</p>
<p class=""><br class="">
</p>
<p class="">Pierre<br class="">
</p>
<br class="">
<div class="moz-cite-prefix">On 12/10/21
16:24, Matthew Knepley wrote:<br class="">
</div>
<blockquote type="cite"
cite="mid:CAMYG4GnECNxUSwDU1zDrRuXP_8rQRdY3a=R7RDDHBWu-nJnA2w@mail.gmail.com"
class="">
<div dir="ltr" class="">
<div dir="ltr" class="">On Tue, Oct 12,
2021 at 10:16 AM Pierre Seize <<a
href="mailto:pierre.seize@onera.fr"
moz-do-not-send="true" class="">pierre.seize@onera.fr</a>>
wrote:<br class="">
</div>
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">Sorry,
I should have tried this before:<br
class="">
<br class="">
I checked out to v3.14, and now both
malloc and PetscMalloc1 are <br
class="">
reported as definitely lost, so I
would say it's a bug.<br class="">
</blockquote>
<div class=""><br class="">
</div>
<div class="">I am not sure what would
be the bug. This is correctly
reporting that you did not free the
memory.</div>
<div class=""><br class="">
</div>
<div class=""> Thanks,</div>
<div class=""><br class="">
</div>
<div class=""> Matt</div>
<div class=""> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
Pierre<br class="">
<br class="">
<br class="">
On 12/10/21 15:58, Pierre Seize
wrote:<br class="">
> Hello petsc-users<br class="">
><br class="">
> I am using Valgrind with my
PETSc application, and I noticed
something:<br class="">
><br class="">
> 1 #include <petscsys.h><br
class="">
> 2<br class="">
> 3 int main(int argc, char
**argv){<br class="">
> 4 PetscErrorCode ierr = 0;<br
class="">
> 5<br class="">
> 6 ierr =
PetscInitialize(&argc,
&argv, NULL, ""); if (ierr)
return <br class="">
> ierr;<br class="">
> 7 PetscReal *foo;<br
class="">
> 8 malloc(sizeof(PetscReal));<br
class="">
> 9 ierr = PetscMalloc1(1,
&foo); CHKERRQ(ierr);<br
class="">
> 10 ierr = PetscFinalize();<br
class="">
> 11 return ierr;<br class="">
> 12 }<br class="">
><br class="">
> With this example, with today's
release branch, I've got this
Valgrind <br class="">
> result (--leak-check=full
--show-leak-kinds=all):<br class="">
><br class="">
> ==2036== Memcheck, a memory
error detector<br class="">
> ==2036== Copyright (C)
2002-2015, and GNU GPL'd, by Julian
Seward et al.<br class="">
> ==2036== Using Valgrind-3.12.0
and LibVEX; rerun with -h for
copyright <br class="">
> info<br class="">
> ==2036== Command:
./build/bin/yanss data/box.yaml<br
class="">
> ==2036==<br class="">
> ==2036==<br class="">
> ==2036== HEAP SUMMARY:<br
class="">
> ==2036== in use at exit:
1,746 bytes in 4 blocks<br class="">
> ==2036== total heap usage:
2,172 allocs, 2,168 frees, 9,624,690
<br class="">
> bytes allocated<br class="">
> ==2036==<br class="">
> ==2036== 8 bytes in 1 blocks
are definitely lost in loss record 1
of 4<br class="">
> ==2036== at 0x4C29BE3:
malloc (vg_replace_malloc.c:299)<br
class="">
> ==2036== by 0x41A4FD: main
(main.c:8)<br class="">
> ==2036==<br class="">
> ==2036== 32 bytes in 1 blocks
are still reachable in loss record 2
of 4<br class="">
> ==2036== at 0x4C2B975:
calloc (vg_replace_malloc.c:711)<br
class="">
> ==2036== by 0xACF461F:
_dlerror_run (in /usr/lib64/<a
href="http://libdl-2.17.so/"
rel="noreferrer" target="_blank"
moz-do-not-send="true" class="">libdl-2.17.so</a>)<br
class="">
> ==2036== by 0xACF4127: dlsym
(in /usr/lib64/<a
href="http://libdl-2.17.so/"
rel="noreferrer" target="_blank"
moz-do-not-send="true" class="">libdl-2.17.so</a>)<br
class="">
> ==2036== by 0x56ECBB5:
PetscInitialize_Common (pinit.c:785)<br
class="">
> ==2036== by 0x56EF325:
PetscInitialize (pinit.c:1203)<br
class="">
> ==2036== by 0x41A4E2: main
(main.c:6)<br class="">
> ==2036==<br class="">
> ==2036== 70 bytes in 1 blocks
are still reachable in loss record 3
of 4<br class="">
> ==2036== at 0x4C29BE3:
malloc (vg_replace_malloc.c:299)<br
class="">
> ==2036== by 0x400F0D0:
_dl_signal_error (in /usr/lib64/<a
href="http://ld-2.17.so/"
rel="noreferrer" target="_blank"
moz-do-not-send="true" class="">ld-2.17.so</a>)<br
class="">
> ==2036== by 0x400F26D:
_dl_signal_cerror (in /usr/lib64/<a
href="http://ld-2.17.so/"
rel="noreferrer" target="_blank"
moz-do-not-send="true" class="">ld-2.17.so</a>)<br
class="">
> ==2036== by 0x400A4BC:
_dl_lookup_symbol_x (in /usr/lib64/<a
href="http://ld-2.17.so/"
rel="noreferrer" target="_blank"
moz-do-not-send="true" class="">ld-2.17.so</a>)<br
class="">
> ==2036== by 0x83B9F02:
do_sym (in /usr/lib64/<a
href="http://libc-2.17.so/"
rel="noreferrer" target="_blank"
moz-do-not-send="true" class="">libc-2.17.so</a>)<br
class="">
> ==2036== by 0xACF40D3:
dlsym_doit (in /usr/lib64/<a
href="http://libdl-2.17.so/"
rel="noreferrer" target="_blank"
moz-do-not-send="true" class="">libdl-2.17.so</a>)<br
class="">
> ==2036== by 0x400F2D3:
_dl_catch_error (in /usr/lib64/<a
href="http://ld-2.17.so/"
rel="noreferrer" target="_blank"
moz-do-not-send="true" class="">ld-2.17.so</a>)<br
class="">
> ==2036== by 0xACF45BC:
_dlerror_run (in /usr/lib64/<a
href="http://libdl-2.17.so/"
rel="noreferrer" target="_blank"
moz-do-not-send="true" class="">libdl-2.17.so</a>)<br
class="">
> ==2036== by 0xACF4127: dlsym
(in /usr/lib64/<a
href="http://libdl-2.17.so/"
rel="noreferrer" target="_blank"
moz-do-not-send="true" class="">libdl-2.17.so</a>)<br
class="">
> ==2036== by 0x56ECBB5:
PetscInitialize_Common (pinit.c:785)<br
class="">
> ==2036== by 0x56EF325:
PetscInitialize (pinit.c:1203)<br
class="">
> ==2036== by 0x41A4E2: main
(main.c:6)<br class="">
> ==2036==<br class="">
> ==2036== 1,636 bytes in 1
blocks are still reachable in loss
record 4 <br class="">
> of 4<br class="">
> ==2036== at 0x4C2BE2D:
memalign (vg_replace_malloc.c:858)<br
class="">
> ==2036== by 0x54AC0CB:
PetscMallocAlign (mal.c:54)<br
class="">
> ==2036== by 0x54AFBA9:
PetscTrMallocDefault (mtr.c:183)<br
class="">
> ==2036== by 0x54ADDD2:
PetscMallocA (mal.c:423)<br class="">
> ==2036== by 0x41A52F: main
(main.c:9)<br class="">
> ==2036==<br class="">
> ==2036== LEAK SUMMARY:<br
class="">
> ==2036== definitely lost: 8
bytes in 1 blocks<br class="">
> ==2036== indirectly lost: 0
bytes in 0 blocks<br class="">
> ==2036== possibly lost: 0
bytes in 0 blocks<br class="">
> ==2036== still reachable:
1,738 bytes in 3 blocks<br class="">
> ==2036== suppressed: 0
bytes in 0 blocks<br class="">
> ==2036==<br class="">
> ==2036== For counts of detected
and suppressed errors, rerun with:
-v<br class="">
> ==2036== ERROR SUMMARY: 1
errors from 1 contexts (suppressed:
0 from 0)<br class="">
><br class="">
><br class="">
> The first report is the malloc
on line 8, fine.<br class="">
> The second and the third
correspond to still reachable memory
from <br class="">
> PetscInitialize on line 6, I
often got these so I usually discard
it.<br class="">
> The fourth and last is the one
that worries me : the memory from <br
class="">
> PetscMalloc1 on line 9 is
reported as "still reachable", but I
don't <br class="">
> think it should.<br class="">
> Is there something I do not
understand, or is this a bug ?<br
class="">
><br class="">
> Thanks in advance,<br class="">
><br class="">
> Pierre<br class="">
<br class="">
</blockquote>
</div>
<br class="" clear="all">
<div class=""><br class="">
</div>
-- <br class="">
<div dir="ltr" class="gmail_signature">
<div dir="ltr" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div dir="ltr" class="">
<div class="">What most
experimenters take for
granted before they begin
their experiments is
infinitely more
interesting than any
results to which their
experiments lead.<br
class="">
-- Norbert Wiener</div>
<div class=""><br class="">
</div>
<div class=""><a
href="http://www.cse.buffalo.edu/%7Eknepley/"
target="_blank"
moz-do-not-send="true"
class="">https://www.cse.buffalo.edu/~knepley/</a><br
class="">
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
<br>
</body>
</html>