<div dir="ltr"><div dir="ltr">On Tue, Oct 12, 2021 at 10:16 AM Pierre Seize <<a href="mailto:pierre.seize@onera.fr">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" class="gmail_signature"><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/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>