[petsc-users] Memory leak when combining PETSc-based vectors and boost::odeint

[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/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20220331/073a5ff0/attachment-0001.html>