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 > <[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/>
