[petsc-users] Still reachable memory in valgrind

Tue Oct 12 09:38:07 CDT 2021

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).

Here I forget to free the memory on purpose, I would like valgrind to 
report it's lost and not still reachable.

Pierre

On 12/10/21 16:24, Matthew Knepley wrote:
> On Tue, Oct 12, 2021 at 10:16 AM Pierre Seize <pierre.seize at onera.fr 
> <mailto:pierre.seize at onera.fr>> wrote:
>
>     Sorry, I should have tried this before:
>
>     I checked out to v3.14, and now both malloc and PetscMalloc1 are
>     reported as definitely lost, so I would say it's a bug.
>
>
> I am not sure what would be the bug. This is correctly reporting that 
> you did not free the memory.
>
>   Thanks,
>
>     Matt
>
>     Pierre
>
>
>     On 12/10/21 15:58, Pierre Seize wrote:
>     > Hello petsc-users
>     >
>     > I am using Valgrind with my PETSc application, and I noticed
>     something:
>     >
>     >  1 #include <petscsys.h>
>     >  2
>     >  3 int main(int argc, char **argv){
>     >  4   PetscErrorCode ierr = 0;
>     >  5
>     >  6   ierr = PetscInitialize(&argc, &argv, NULL, ""); if (ierr)
>     return
>     > ierr;
>     >  7   PetscReal *foo;
>     >  8   malloc(sizeof(PetscReal));
>     >  9   ierr = PetscMalloc1(1, &foo); CHKERRQ(ierr);
>     > 10   ierr = PetscFinalize();
>     > 11   return ierr;
>     > 12 }
>     >
>     > With this example, with today's release branch, I've got this
>     Valgrind
>     > result (--leak-check=full --show-leak-kinds=all):
>     >
>     > ==2036== Memcheck, a memory error detector
>     > ==2036== Copyright (C) 2002-2015, and GNU GPL'd, by Julian
>     Seward et al.
>     > ==2036== Using Valgrind-3.12.0 and LibVEX; rerun with -h for
>     copyright
>     > info
>     > ==2036== Command: ./build/bin/yanss data/box.yaml
>     > ==2036==
>     > ==2036==
>     > ==2036== HEAP SUMMARY:
>     > ==2036==     in use at exit: 1,746 bytes in 4 blocks
>     > ==2036==   total heap usage: 2,172 allocs, 2,168 frees, 9,624,690
>     > bytes allocated
>     > ==2036==
>     > ==2036== 8 bytes in 1 blocks are definitely lost in loss record
>     1 of 4
>     > ==2036==    at 0x4C29BE3: malloc (vg_replace_malloc.c:299)
>     > ==2036==    by 0x41A4FD: main (main.c:8)
>     > ==2036==
>     > ==2036== 32 bytes in 1 blocks are still reachable in loss record
>     2 of 4
>     > ==2036==    at 0x4C2B975: calloc (vg_replace_malloc.c:711)
>     > ==2036==    by 0xACF461F: _dlerror_run (in
>     /usr/lib64/libdl-2.17.so <http://libdl-2.17.so>)
>     > ==2036==    by 0xACF4127: dlsym (in /usr/lib64/libdl-2.17.so
>     <http://libdl-2.17.so>)
>     > ==2036==    by 0x56ECBB5: PetscInitialize_Common (pinit.c:785)
>     > ==2036==    by 0x56EF325: PetscInitialize (pinit.c:1203)
>     > ==2036==    by 0x41A4E2: main (main.c:6)
>     > ==2036==
>     > ==2036== 70 bytes in 1 blocks are still reachable in loss record
>     3 of 4
>     > ==2036==    at 0x4C29BE3: malloc (vg_replace_malloc.c:299)
>     > ==2036==    by 0x400F0D0: _dl_signal_error (in
>     /usr/lib64/ld-2.17.so <http://ld-2.17.so>)
>     > ==2036==    by 0x400F26D: _dl_signal_cerror (in
>     /usr/lib64/ld-2.17.so <http://ld-2.17.so>)
>     > ==2036==    by 0x400A4BC: _dl_lookup_symbol_x (in
>     /usr/lib64/ld-2.17.so <http://ld-2.17.so>)
>     > ==2036==    by 0x83B9F02: do_sym (in /usr/lib64/libc-2.17.so
>     <http://libc-2.17.so>)
>     > ==2036==    by 0xACF40D3: dlsym_doit (in
>     /usr/lib64/libdl-2.17.so <http://libdl-2.17.so>)
>     > ==2036==    by 0x400F2D3: _dl_catch_error (in
>     /usr/lib64/ld-2.17.so <http://ld-2.17.so>)
>     > ==2036==    by 0xACF45BC: _dlerror_run (in
>     /usr/lib64/libdl-2.17.so <http://libdl-2.17.so>)
>     > ==2036==    by 0xACF4127: dlsym (in /usr/lib64/libdl-2.17.so
>     <http://libdl-2.17.so>)
>     > ==2036==    by 0x56ECBB5: PetscInitialize_Common (pinit.c:785)
>     > ==2036==    by 0x56EF325: PetscInitialize (pinit.c:1203)
>     > ==2036==    by 0x41A4E2: main (main.c:6)
>     > ==2036==
>     > ==2036== 1,636 bytes in 1 blocks are still reachable in loss
>     record 4
>     > of 4
>     > ==2036==    at 0x4C2BE2D: memalign (vg_replace_malloc.c:858)
>     > ==2036==    by 0x54AC0CB: PetscMallocAlign (mal.c:54)
>     > ==2036==    by 0x54AFBA9: PetscTrMallocDefault (mtr.c:183)
>     > ==2036==    by 0x54ADDD2: PetscMallocA (mal.c:423)
>     > ==2036==    by 0x41A52F: main (main.c:9)
>     > ==2036==
>     > ==2036== LEAK SUMMARY:
>     > ==2036==    definitely lost: 8 bytes in 1 blocks
>     > ==2036==    indirectly lost: 0 bytes in 0 blocks
>     > ==2036==      possibly lost: 0 bytes in 0 blocks
>     > ==2036==    still reachable: 1,738 bytes in 3 blocks
>     > ==2036==         suppressed: 0 bytes in 0 blocks
>     > ==2036==
>     > ==2036== For counts of detected and suppressed errors, rerun
>     with: -v
>     > ==2036== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0
>     from 0)
>     >
>     >
>     > The first report is the malloc on line 8, fine.
>     > The second and the third correspond to still reachable memory from
>     > PetscInitialize on line 6, I often got these so I usually
>     discard it.
>     > The fourth and last is the one that worries me : the memory from
>     > PetscMalloc1 on line 9 is reported as "still reachable", but I
>     don't
>     > think it should.
>     > Is there something I do not understand, or is this a bug ?
>     >
>     > Thanks in advance,
>     >
>     > Pierre
>
>
>
> -- 
> 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
>
> https://www.cse.buffalo.edu/~knepley/ 
> <http://www.cse.buffalo.edu/%7Eknepley/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20211012/c5558a37/attachment.html>