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

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