[petsc-users] Still reachable memory in valgrind

Barry Smith bsmith at petsc.dev
Tue Oct 12 09:34:28 CDT 2021


  I think that 4) is normal. PetscMalloc() is just a wrapper for malloc, PETSc does not free the space obtained with PetscMalloc() at PetscFinalize() so that memory is still available and usable after PetscFinalize() (Of course we do not recommend using it).  

  PETSc has an option -malloc_dump that will print out all the memory obtained with PetscMalloc() that has not been freed at PetscFinalize() which is a quick way to find any  PetscMalloc() without free.

   Barry


> On Oct 12, 2021, at 9:58 AM, Pierre Seize <Pierre.Seize at onera.fr> 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)
> ==2036==    by 0xACF4127: dlsym (in /usr/lib64/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)
> ==2036==    by 0x400F26D: _dl_signal_cerror (in /usr/lib64/ld-2.17.so)
> ==2036==    by 0x400A4BC: _dl_lookup_symbol_x (in /usr/lib64/ld-2.17.so)
> ==2036==    by 0x83B9F02: do_sym (in /usr/lib64/libc-2.17.so)
> ==2036==    by 0xACF40D3: dlsym_doit (in /usr/lib64/libdl-2.17.so)
> ==2036==    by 0x400F2D3: _dl_catch_error (in /usr/lib64/ld-2.17.so)
> ==2036==    by 0xACF45BC: _dlerror_run (in /usr/lib64/libdl-2.17.so)
> ==2036==    by 0xACF4127: dlsym (in /usr/lib64/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



More information about the petsc-users mailing list