[petsc-users] Still reachable memory in valgrind
Pierre Seize
pierre.seize at onera.fr
Tue Oct 12 10:19:04 CDT 2021
Thank you !
I configured both with the same options, but maybe the default have
changed between versions.
Now I understand. And thank you for the -malloc_dump option, I forgot
about it.
Pierre
On 12/10/21 17:16, Barry Smith wrote:
>
> 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
>> <mailto: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/78310b36/attachment-0001.html>
More information about the petsc-users
mailing list