[petsc-users] Still reachable memory in valgrind

Stefano Zampini stefano.zampini at gmail.com
Tue Oct 12 10:17:29 CDT 2021 

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.

Il giorno mar 12 ott 2021 alle ore 18:07 Pierre Seize <pierre.seize at onera.fr>
ha scritto:

> With 3.14 : both malloc and PetscMalloc1 are definitely lost, which is
> what I want:
>
> ==5463== Memcheck, a memory error detector
> ==5463== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
> ==5463== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
> ==5463== Command: ./build/bin/yanss data/box.yaml
> ==5463==
> ==5463==
> ==5463== HEAP SUMMARY:
> ==5463==     in use at exit: 48 bytes in 3 blocks
> ==5463==   total heap usage: 2,092 allocs, 2,089 frees, 9,139,664 bytes
> allocated
> ==5463==
> ==5463== 8 bytes in 1 blocks are definitely lost in loss record 1 of 3
> ==5463==    at 0x4C29BE3: malloc (vg_replace_malloc.c:299)
> ==5463==    by 0x4191A1: main (main.c:62)
> ==5463==
> ==5463== 8 bytes in 1 blocks are definitely lost in loss record 2 of 3
> ==5463==    at 0x4C2BE2D: memalign (vg_replace_malloc.c:858)
> ==5463==    by 0x5655AEF: PetscMallocAlign (mal.c:52)
> ==5463==    by 0x5657465: PetscMallocA (mal.c:425)
> ==5463==    by 0x4191D3: main (main.c:63)
> ==5463==
> ==5463== LEAK SUMMARY:
> ==5463==    definitely lost: 16 bytes in 2 blocks
> ==5463==    indirectly lost: 0 bytes in 0 blocks
> ==5463==      possibly lost: 0 bytes in 0 blocks
> ==5463==    still reachable: 32 bytes in 1 blocks
> ==5463==         suppressed: 0 bytes in 0 blocks
> ==5463== Reachable blocks (those to which a pointer was found) are not
> shown.
> ==5463== To see them, rerun with: --leak-check=full --show-leak-kinds=all
> ==5463==
> ==5463== For counts of detected and suppressed errors, rerun with: -v
> ==5463== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
> 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.
> 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 ?
>
> Thank you for your time
> Pierre
>
> On 12/10/21 16:51, Barry Smith wrote:
>
>
>   Do you have the valgrind output from 3.14 ?
>
> 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==
>
>
> 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.
>
> Barry
>
>
>
> On Oct 12, 2021, at 10:38 AM, Pierre Seize <Pierre.Seize at onera.fr> wrote:
>
> 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>
> 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)
>> > ==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
>>
>>
>
> --
> 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/>
>
>
>
>
>

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

More information about the petsc-users mailing list