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 [0]PETSC ERROR: Object already free: Parameter # 1 [0]PETSC ERROR: See 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]> wrote: > > 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() > > 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]> 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]> 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/>
