[petsc-users] Still reachable memory in valgrind
Barry Smith
bsmith at petsc.dev
Tue Oct 12 10:16:38 CDT 2021
Notice with your 3.14
> 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)
>
>
but with your 3.15
>>>> > ==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)
note the
>>>> PetscTrMallocDefault
so with 3.15 it is using the "tracing" version of PETSc malloc which keeps a list of unfreeded memory but with 3.14 it is not using the tracing version. This could happen because 3.14 was configured with --with-debugging=0 while 3.15 was not. Or having -malloc_debug in the environmental variable PETSC_OPTIONS. But I don't think it is due to any changes in the PETSc source code.
Barry
> On Oct 12, 2021, at 11:06 AM, Pierre Seize <Pierre.Seize at onera.fr> wrote:
>
> 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 <mailto: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 <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/7c270a8f/attachment-0001.html>
More information about the petsc-users
mailing list