<div dir="ltr">Your are using two different mallocs in PETSc. For your 3.14 test, PetscMallocAlign is used, while for 3.16, PetscTrMallocDefault is called, which uses much more memory to trace memory corruption previous allocated PETSc data.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno mar 12 ott 2021 alle ore 18:07 Pierre Seize <<a href="mailto:pierre.seize@onera.fr">pierre.seize@onera.fr</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>With 3.14 : both malloc and PetscMalloc1 are definitely lost,
which is what I want:</p>
<p><tt>==5463== Memcheck, a memory error detector</tt><br>
<tt>==5463== Copyright (C) 2002-2015, and GNU GPL'd, by Julian
Seward et al.</tt><br>
<tt>==5463== Using Valgrind-3.12.0 and LibVEX; rerun with -h for
copyright info</tt><br>
<tt>==5463== Command: ./build/bin/yanss data/box.yaml</tt><br>
<tt>==5463== </tt><br>
<tt>==5463== </tt><br>
<tt>==5463== HEAP SUMMARY:</tt><br>
<tt>==5463== in use at exit: 48 bytes in 3 blocks</tt><br>
<tt>==5463== total heap usage: 2,092 allocs, 2,089 frees,
9,139,664 bytes allocated</tt><br>
<tt>==5463== </tt><br>
<tt>==5463== 8 bytes in 1 blocks are definitely lost in loss
record 1 of 3</tt><br>
<tt>==5463== at 0x4C29BE3: malloc (vg_replace_malloc.c:299)</tt><br>
<tt>==5463== by 0x4191A1: main (main.c:62)</tt><br>
<tt>==5463== </tt><br>
<tt>==5463== 8 bytes in 1 blocks are definitely lost in loss
record 2 of 3</tt><br>
<tt>==5463== at 0x4C2BE2D: memalign (vg_replace_malloc.c:858)</tt><br>
<tt>==5463== by 0x5655AEF: PetscMallocAlign (mal.c:52)</tt><br>
<tt>==5463== by 0x5657465: PetscMallocA (mal.c:425)</tt><br>
<tt>==5463== by 0x4191D3: main (main.c:63)</tt><br>
<tt>==5463== </tt><br>
<tt>==5463== LEAK SUMMARY:</tt><br>
<tt>==5463== definitely lost: 16 bytes in 2 blocks</tt><br>
<tt>==5463== indirectly lost: 0 bytes in 0 blocks</tt><br>
<tt>==5463== possibly lost: 0 bytes in 0 blocks</tt><br>
<tt>==5463== still reachable: 32 bytes in 1 blocks</tt><br>
<tt>==5463== suppressed: 0 bytes in 0 blocks</tt><br>
<tt>==5463== Reachable blocks (those to which a pointer was found)
are not shown.</tt><br>
<tt>==5463== To see them, rerun with: --leak-check=full
--show-leak-kinds=all</tt><br>
<tt>==5463== </tt><br>
<tt>==5463== For counts of detected and suppressed errors, rerun
with: -v</tt><br>
<tt>==5463== ERROR SUMMARY: 2 errors from 2 contexts (suppressed:
0 from 0)</tt><br>
</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>
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>
<br>
Thank you for your time<br>
Pierre<br>
<br>
<div>On 12/10/21 16:51, Barry Smith wrote:<br>
</div>
<blockquote type="cite">
<div><br>
</div>
Do you have the valgrind output from 3.14 ?
<div><br>
</div>
<div>
<blockquote type="cite" style="background-color:rgb(255,255,255)">
<div dir="ltr">
<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">1,636 bytes in 1 blocks are still reachable in
loss record 4 <br>
> of 4<br>
> ==2036== at 0x4C2BE2D: memalign
(vg_replace_malloc.c:858)<br>
> ==2036== by 0x54AC0CB: PetscMallocAlign
(mal.c:54)<br>
> ==2036== by 0x54AFBA9: PetscTrMallocDefault
(mtr.c:183)<br>
> ==2036== by 0x54ADDD2: PetscMallocA (mal.c:423)<br>
> ==2036== by 0x41A52F: main (main.c:9)<br>
> ==2036==</blockquote>
</div>
</div>
</blockquote>
<div><br>
</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><br>
</div>
<div>Barry</div>
<div><br>
</div>
<div> <br>
<div><br>
<blockquote type="cite">
<div>On Oct 12, 2021, at 10:38 AM, Pierre Seize
<<a href="mailto:Pierre.Seize@onera.fr" target="_blank">Pierre.Seize@onera.fr</a>>
wrote:</div>
<br>
<div>
<div bgcolor="#FFFFFF">
<p>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>Here I forget to free the memory on purpose,
I would like valgrind to report it's lost and not
still reachable.</p>
<p><br>
</p>
<p>Pierre<br>
</p>
<br>
<div>On 12/10/21 16:24, Matthew
Knepley wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">On Tue, Oct 12, 2021 at
10:16 AM Pierre Seize <<a href="mailto:pierre.seize@onera.fr" target="_blank">pierre.seize@onera.fr</a>>
wrote:<br>
</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>
<br>
I checked out to v3.14, and now both malloc and
PetscMalloc1 are <br>
reported as definitely lost, so I would say it's
a bug.<br>
</blockquote>
<div><br>
</div>
<div>I am not sure what would be the bug.
This is correctly reporting that you did not
free the memory.</div>
<div><br>
</div>
<div> Thanks,</div>
<div><br>
</div>
<div> Matt</div>
<div> </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>
<br>
<br>
On 12/10/21 15:58, Pierre Seize wrote:<br>
> Hello petsc-users<br>
><br>
> I am using Valgrind with my PETSc
application, and I noticed something:<br>
><br>
> 1 #include <petscsys.h><br>
> 2<br>
> 3 int main(int argc, char **argv){<br>
> 4 PetscErrorCode ierr = 0;<br>
> 5<br>
> 6 ierr = PetscInitialize(&argc,
&argv, NULL, ""); if (ierr) return <br>
> ierr;<br>
> 7 PetscReal *foo;<br>
> 8 malloc(sizeof(PetscReal));<br>
> 9 ierr = PetscMalloc1(1, &foo);
CHKERRQ(ierr);<br>
> 10 ierr = PetscFinalize();<br>
> 11 return ierr;<br>
> 12 }<br>
><br>
> With this example, with today's release
branch, I've got this Valgrind <br>
> result (--leak-check=full
--show-leak-kinds=all):<br>
><br>
> ==2036== Memcheck, a memory error detector<br>
> ==2036== Copyright (C) 2002-2015, and GNU
GPL'd, by Julian Seward et al.<br>
> ==2036== Using Valgrind-3.12.0 and LibVEX;
rerun with -h for copyright <br>
> info<br>
> ==2036== Command: ./build/bin/yanss
data/box.yaml<br>
> ==2036==<br>
> ==2036==<br>
> ==2036== HEAP SUMMARY:<br>
> ==2036== in use at exit: 1,746 bytes in
4 blocks<br>
> ==2036== total heap usage: 2,172 allocs,
2,168 frees, 9,624,690 <br>
> bytes allocated<br>
> ==2036==<br>
> ==2036== 8 bytes in 1 blocks are definitely
lost in loss record 1 of 4<br>
> ==2036== at 0x4C29BE3: malloc
(vg_replace_malloc.c:299)<br>
> ==2036== by 0x41A4FD: main (main.c:8)<br>
> ==2036==<br>
> ==2036== 32 bytes in 1 blocks are still
reachable in loss record 2 of 4<br>
> ==2036== at 0x4C2B975: calloc
(vg_replace_malloc.c:711)<br>
> ==2036== by 0xACF461F: _dlerror_run (in
/usr/lib64/<a href="http://libdl-2.17.so/" rel="noreferrer" target="_blank">libdl-2.17.so</a>)<br>
> ==2036== by 0xACF4127: dlsym (in
/usr/lib64/<a href="http://libdl-2.17.so/" rel="noreferrer" target="_blank">libdl-2.17.so</a>)<br>
> ==2036== by 0x56ECBB5:
PetscInitialize_Common (pinit.c:785)<br>
> ==2036== by 0x56EF325: PetscInitialize
(pinit.c:1203)<br>
> ==2036== by 0x41A4E2: main (main.c:6)<br>
> ==2036==<br>
> ==2036== 70 bytes in 1 blocks are still
reachable in loss record 3 of 4<br>
> ==2036== at 0x4C29BE3: malloc
(vg_replace_malloc.c:299)<br>
> ==2036== by 0x400F0D0: _dl_signal_error
(in /usr/lib64/<a href="http://ld-2.17.so/" rel="noreferrer" target="_blank">ld-2.17.so</a>)<br>
> ==2036== by 0x400F26D: _dl_signal_cerror
(in /usr/lib64/<a href="http://ld-2.17.so/" rel="noreferrer" target="_blank">ld-2.17.so</a>)<br>
> ==2036== by 0x400A4BC:
_dl_lookup_symbol_x (in /usr/lib64/<a href="http://ld-2.17.so/" rel="noreferrer" target="_blank">ld-2.17.so</a>)<br>
> ==2036== by 0x83B9F02: do_sym (in
/usr/lib64/<a href="http://libc-2.17.so/" rel="noreferrer" target="_blank">libc-2.17.so</a>)<br>
> ==2036== by 0xACF40D3: dlsym_doit (in
/usr/lib64/<a href="http://libdl-2.17.so/" rel="noreferrer" target="_blank">libdl-2.17.so</a>)<br>
> ==2036== by 0x400F2D3: _dl_catch_error
(in /usr/lib64/<a href="http://ld-2.17.so/" rel="noreferrer" target="_blank">ld-2.17.so</a>)<br>
> ==2036== by 0xACF45BC: _dlerror_run (in
/usr/lib64/<a href="http://libdl-2.17.so/" rel="noreferrer" target="_blank">libdl-2.17.so</a>)<br>
> ==2036== by 0xACF4127: dlsym (in
/usr/lib64/<a href="http://libdl-2.17.so/" rel="noreferrer" target="_blank">libdl-2.17.so</a>)<br>
> ==2036== by 0x56ECBB5:
PetscInitialize_Common (pinit.c:785)<br>
> ==2036== by 0x56EF325: PetscInitialize
(pinit.c:1203)<br>
> ==2036== by 0x41A4E2: main (main.c:6)<br>
> ==2036==<br>
> ==2036== 1,636 bytes in 1 blocks are still
reachable in loss record 4 <br>
> of 4<br>
> ==2036== at 0x4C2BE2D: memalign
(vg_replace_malloc.c:858)<br>
> ==2036== by 0x54AC0CB: PetscMallocAlign
(mal.c:54)<br>
> ==2036== by 0x54AFBA9:
PetscTrMallocDefault (mtr.c:183)<br>
> ==2036== by 0x54ADDD2: PetscMallocA
(mal.c:423)<br>
> ==2036== by 0x41A52F: main (main.c:9)<br>
> ==2036==<br>
> ==2036== LEAK SUMMARY:<br>
> ==2036== definitely lost: 8 bytes in 1
blocks<br>
> ==2036== indirectly lost: 0 bytes in 0
blocks<br>
> ==2036== possibly lost: 0 bytes in 0
blocks<br>
> ==2036== still reachable: 1,738 bytes in
3 blocks<br>
> ==2036== suppressed: 0 bytes in 0
blocks<br>
> ==2036==<br>
> ==2036== For counts of detected and
suppressed errors, rerun with: -v<br>
> ==2036== ERROR SUMMARY: 1 errors from 1
contexts (suppressed: 0 from 0)<br>
><br>
><br>
> The first report is the malloc on line 8,
fine.<br>
> The second and the third correspond to
still reachable memory from <br>
> PetscInitialize on line 6, I often got
these so I usually discard it.<br>
> The fourth and last is the one that worries
me : the memory from <br>
> PetscMalloc1 on line 9 is reported as
"still reachable", but I don't <br>
> think it should.<br>
> Is there something I do not understand, or
is this a bug ?<br>
><br>
> Thanks in advance,<br>
><br>
> Pierre<br>
<br>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>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</div>
<div><br>
</div>
<div><a href="http://www.cse.buffalo.edu/%7Eknepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">Stefano</div>