On Fri, 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 > [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. > > What code is setting that pointer to NULL? Thanks, Matt > 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 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]> >> 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/> > > -- 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/>
