On Thu, Mar 31, 2022 at 5:58 AM Roland Richter <[email protected]> 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/>
