[petsc-users] Memory leak when combining PETSc-based vectors and boost::odeint
Roland Richter
roland.richter at ntnu.no
Fri Apr 1 06:22:02 CDT 2022
In my destructor I have the following phrase:
/ if(local_vec != PETSC_NULL) {//
// PetscInt vecSize = 0;//
// PetscErrorCode ierr;//
// std::cerr << local_vec << '\n';//
// ierr = VecGetSize(local_vec, &vecSize);//
// std::cerr << vecSize << '\t' << ierr << '\n';//
// ierr = VecDestroy(&local_vec);//
// std::cerr << vecSize << '\t' << ierr << '\n';//
// local_vec = PETSC_NULL;//
// }/
which should set /local_vec/ to /PETSC_NULL/ as soon as it is no longer
in use.
Regards,
Roland
Am 01.04.22 um 13:19 schrieb Matthew Knepley:
> On Fri, Apr 1, 2022 at 6:50 AM Roland Richter <roland.richter at ntnu.no>
> wrote:
>
> I re-run my code with a debug version of PETSc, resulting in
>
> [0]PETSC ERROR: --------------------- Error Message
> --------------------------------------------------------------
> [0]PETSC ERROR: Corrupt argument:
> https://petsc.org/release/faq/#valgrind
> [0]PETSC ERROR: Object already free: Parameter # 1
> [0]PETSC ERROR: See https://petsc.org/release/faq/ for trouble
> shooting.
> [0]PETSC ERROR: Petsc Development GIT revision:
> v3.17.0-8-gf6d6129e50 GIT Date: 2022-03-31 18:10:33 +0000
> [0]PETSC ERROR: #1 VecGetSize() at
> /home/roland/Downloads/git-files/petsc/src/vec/vec/interface/vector.c:670
> 0 64
> [0]PETSC ERROR: #2 VecDestroy() at
> /home/roland/Downloads/git-files/petsc/src/vec/vec/interface/vector.c:375
> 0 64
> [0]PETSC ERROR: #3 VecGetArray() at
> /home/roland/Downloads/git-files/petsc/src/vec/vec/interface/rvector.c:1780
>
> I do not understand why it tries to access the vector, even though
> it has been set to PETSC_NULL in the previous free-call.
>
> What code is setting that pointer to NULL?
>
> Thanks,
>
> Matt
>
> Regards,
>
> Roland
>
> Am 31.03.22 um 15:50 schrieb Matthew Knepley:
>> On Thu, Mar 31, 2022 at 9:47 AM Roland Richter
>> <roland.richter at ntnu.no> wrote:
>>
>> The backtrace is
>>
>> #0 0x00007fffeec4ba97in VecGetSize_Seq() from
>> /opt/petsc/lib/libpetsc.so.3.016
>> #1 0x00007fffeec78f5ain VecGetSize() from
>> /opt/petsc/lib/libpetsc.so.3.016
>> #2 0x0000000000410b73in
>> test_ts_arma_with_pure_petsc_preconfigured_clean(unsigned
>> long, unsigned long, arma::Col<std::complex<doubl
>> e> > const&, arma::Col<std::complex<double> >&, double,
>> double, double) [clone .constprop.0]()
>> #3 0x0000000000414384in test_RK4_solvers_clean(unsigned
>> long, unsigned long, unsigned long, bool) [clone .constprop.0]()
>> #4 0x0000000000405c6cin main()
>>
>> It looks like you are passing an invalid vector. If you compiled
>> in debug mode, it would tell you. I would run
>> in debug until my code was running like I expect, then switch to
>> optimized. You can do that by using two
>> different PETSC_ARCH configures, and switch at runtime with that
>> variable.
>>
>> Thanks,
>>
>> Matt
>>
>> Regards,
>>
>> Roland Richter
>>
>> Am 31.03.22 um 15:35 schrieb Matthew Knepley:
>>> On Thu, Mar 31, 2022 at 9:01 AM Roland Richter
>>> <roland.richter at ntnu.no> wrote:
>>>
>>> Hei,
>>>
>>> Thanks for the idea! I added a simple std::cout for both
>>> constructor and destructor, and found out that my
>>> destructor is called multiple times, while the
>>> constructor is called only once. This could explain the
>>> error (double free), but I do not know why segfault is
>>> thrown even though I explicitly check if the vector has
>>> been used. Are there explanations for that?
>>>
>>> Run with -start_in_debugger and get the stack trace when it
>>> faults. Right now, I have no idea where it is faulting.
>>>
>>> Thanks,
>>>
>>> Matt
>>>
>>>
>>> Regards,
>>>
>>> Roland Richter
>>>
>>> Am 31.03.22 um 12:14 schrieb Matthew Knepley:
>>>> On Thu, Mar 31, 2022 at 5:58 AM Roland Richter
>>>> <roland.richter at ntnu.no> wrote:
>>>>
>>>> Hei,
>>>>
>>>> For a project I wanted to combine boost::odeint for
>>>> timestepping and PETSc-based vectors and matrices
>>>> for calculating the right hand side. As comparison
>>>> for both timing and correctness I set up an
>>>> armadillo-based right hand side (with the
>>>> main-function being in *main.cpp*, and the test
>>>> code in *test_timestepping_clean.cpp*)
>>>>
>>>> In theory, the code works fine, but I have some
>>>> issues with cleaning up afterwards in my struct
>>>> /Petsc_RHS_state_clean/. My initial intention was
>>>> to set up all involved matrices and vectors within
>>>> the constructor, and free the memory in the
>>>> destructor. To avoid freeing vectors I have not
>>>> used I initially set them to /PETSC_NULL/, and
>>>> check if this value has been changed before calling
>>>> /VecDestroy()./
>>>>
>>>> You do not need to check. Destroy() functions already
>>>> check for NULL.
>>>>
>>>> However, when doing that I get the following error:
>>>>
>>>> [0]PETSC ERROR:
>>>> ------------------------------------------------------------------------
>>>>
>>>> [0]PETSC ERROR: Caught signal number 11 SEGV:
>>>> Segmentation Violation, probably memory access out
>>>> of range
>>>> [0]PETSC ERROR: Try option -start_in_debugger or
>>>> -on_error_attach_debugger
>>>> [0]PETSC ERROR: or see
>>>> https://petsc.org/release/faq/#valgrind
>>>> [0]PETSC ERROR: or try http://valgrind.org on
>>>> GNU/linux and Apple Mac OS X to find memory
>>>> corruption errors
>>>> [0]PETSC ERROR: configure using
>>>> --with-debugging=yes, recompile, link, and run
>>>> [0]PETSC ERROR: to get more information on the crash.
>>>> [0]PETSC ERROR: --------------------- Error Message
>>>> --------------------------------------------------------------
>>>>
>>>> If I comment out that code in
>>>> ~Petsc_RHS_state_clean(), the program runs, but
>>>> will use ~17 GByte of RAM during runtime. As the
>>>> memory is not used immediately in full, but rather
>>>> increases during running, I assume a memory leak
>>>> somewhere. Where does it come from, and how can I
>>>> avoid it?
>>>>
>>>> It must be that your constructor is called multiple
>>>> times without calling your destructor. I cannot
>>>> understand this code in order
>>>> to see where that happens, but you should just be
>>>> able to run in the debugger and put a break point at
>>>> the creation and
>>>> destruction calls.
>>>>
>>>> Thanks,
>>>>
>>>> Matt
>>>>
>>>> Thanks!
>>>>
>>>> Regards,
>>>>
>>>> Roland Richter
>>>>
>>>>
>>>>
>>>> --
>>>> 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/~knepley/>
>>>
>>>
>>>
>>> --
>>> 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/~knepley/>
>>
>>
>>
>> --
>> 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/~knepley/>
>
>
>
> --
> 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/~knepley/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20220401/c3fe7c2c/attachment-0001.html>
More information about the petsc-users
mailing list