I recommend first running with valgrind. I tried to build your code but got compile errors from arma:: being unknown. Where does it come from? Is it only in a super new version of Boost?
> On Apr 1, 2022, at 6:50 AM, Roland Richter <[email protected]> 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 > <https://petsc.org/release/faq/#valgrind> > [0]PETSC ERROR: Object already free: Parameter # 1 > [0]PETSC ERROR: See https://petsc.org/release/faq/ > <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. > > Regards, > > Roland > > Am 31.03.22 um 15:50 schrieb Matthew Knepley: >> On Thu, Mar 31, 2022 at 9:47 AM Roland Richter <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >>> <mailto:[email protected]>> 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 <[email protected] >>>> <mailto:[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 >>>> <https://petsc.org/release/faq/#valgrind> >>>> [0]PETSC ERROR: or try http://valgrind.org <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/>
