[petsc-users] Memory leak when combining PETSc-based vectors and boost::odeint
Matthew Knepley
knepley at gmail.com
Fri Apr 1 06:31:26 CDT 2022
On Fri, Apr 1, 2022 at 7:22 AM Roland Richter <roland.richter at ntnu.no>
wrote:
> 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.
>
You must be copying that pointer somewhere in your code.
Thanks,
Matt
> 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 0x00007fffeec4ba97 in VecGetSize_Seq () from
>>> /opt/petsc/lib/libpetsc.so.3.016
>>> #1 0x00007fffeec78f5a in VecGetSize () from
>>> /opt/petsc/lib/libpetsc.so.3.016
>>> #2 0x0000000000410b73 in 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 0x0000000000414384 in test_RK4_solvers_clean(unsigned long,
>>> unsigned long, unsigned long, bool) [clone .constprop.0] ()
>>> #4 0x0000000000405c6c in 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/>
>
>
--
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/7249d057/attachment-0001.html>
More information about the petsc-users
mailing list