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

[Roland Richter]

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()

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