What is the signature of `integrate_adaptive()`? As Matt points out you may be copying the pointer somewhere, maybe `integrate_adaptive()` is copy-constructing its `local_calculator` argument (and hence its `local_vector`)?
Best regards, Jacob Faibussowitsch (Jacob Fai - booss - oh - vitch) > On Apr 1, 2022, at 10:57, Barry Smith <[email protected]> wrote: > > > I don't know why valgrind is not putting in line numbers but something is > clearly very wrong with data structure initialization. I am not sure if it is > really directly related to PETSc but somehow comes about in the C++ > constructor business, which seems simple enough in your code but I don't > understand. When working with MPI and C++ one must be careful that no > constructors of global objects that reference MPI get called before MPI is > initialized but that doesn't seem to be happening in your code. > > Sorry, I can debug it but I have no clue how to build your code it seems to > use "armadillo-matrices" stuff that somehow doesn't come in through any > include files or libraries. If you gave me a full makefile that builds > everything I might be able to build it. > >> On Apr 1, 2022, at 9:56 AM, Roland Richter <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hei, >> >> It defines the namespace used for armadillo-matrices. A valgrind-log is >> attached for the case with removed destructor (can't run valgrind if my >> program fails with a segfault). >> >> Regards, >> >> Roland >> >> Am 01.04.22 um 15:23 schrieb Barry Smith: >>> >>> 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] >>>> <mailto:[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/> >>> >> <out_file.txt> >
