[petsc-users] Memory leak when combining PETSc-based vectors and boost::odeint
Roland Richter
roland.richter at ntnu.no
Fri Apr 1 05:50:38 CDT 2022
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
> <roland.richter at ntnu.no> 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
>> <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> 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/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20220401/d78950f2/attachment-0001.html>
More information about the petsc-users
mailing list