[petsc-users] Memory leak when combining PETSc-based vectors and boost::odeint

Barry Smith bsmith at petsc.dev
Fri Apr 1 08:23:50 CDT 2022 

  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 <roland.richter at ntnu.no> 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 <roland.richter at ntnu.no <mailto:roland.richter at ntnu.no>> 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 <roland.richter at ntnu.no <mailto:roland.richter at ntnu.no>> 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 <roland.richter at ntnu.no <mailto:roland.richter at ntnu.no>> 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/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20220401/33312958/attachment.html>

More information about the petsc-users mailing list