Memory leak / unconverted smart pointers in down_cast().mat()

Have you imported PyTrilinos before you do the downcast for the Epetra
backend?

Johan

On 02/21/2012 12:45 PM, Joachim Haga wrote:
> Public bug reported:
>
> A memory leak is reported when doing down_cast(A).mat() in python.
> Additionally, the smart-pointer object that is returned is not converted
> to a usable type. This is tested with trunk, I assume the same happens
> in 1.0. PETSc v3.2-p5, Trilinos v10.85.
>
> Test code:
> ========
> from dolfin import *
> dolfin.parameters["linear_algebra_backend"] = "Epetra" # also with PETSc
>
> mesh = UnitSquare(2,2)
> V = FunctionSpace(mesh, "CG", 1)
> v, u = TestFunction(V), TrialFunction(V)
> A = assemble(inner(grad(u),grad(v))*dx)
>
> C = down_cast(A).mat()
> print C
>
> Output:
> ======
> <Swig Object of type 'Teuchos::RCP< Epetra_FECrsMatrix> *' at 0x9fb5140>
> swig/python detected a memory leak of type 'Teuchos::RCP< Epetra_FECrsMatrix> *', no destructor found.
>
> ** Affects: dolfin
> Importance: Undecided
> Status: New
>

That did the trick! I thought that explicitly importing PyTrilinos import
was no longer needed with the recent(ish) MPI fixes in Trilinos.

I'm thinking it would be nice if it weren't necessary... and if it didn't
leak memory when PyTrilinos/PyPETSc isn't imported... but that's not vital
right now.

-j.

On 21 February 2012 12:55, Johan Hake <email address hidden> wrote:

> Have you imported PyTrilinos before you do the downcast for the Epetra
> backend?
>
> Johan
>
> On 02/21/2012 12:45 PM, Joachim Haga wrote:
> > Public bug reported:
> >
> > A memory leak is reported when doing down_cast(A).mat() in python.
> > Additionally, the smart-pointer object that is returned is not converted
> > to a usable type. This is tested with trunk, I assume the same happens
> > in 1.0. PETSc v3.2-p5, Trilinos v10.85.
> >
> > Test code:
> > ========
> > from dolfin import *
> > dolfin.parameters["linear_algebra_backend"] = "Epetra" # also with PETSc
> >
> > mesh = UnitSquare(2,2)
> > V = FunctionSpace(mesh, "CG", 1)
> > v, u = TestFunction(V), TrialFunction(V)
> > A = assemble(inner(grad(u),grad(v))*dx)
> >
> > C = down_cast(A).mat()
> > print C
> >
> > Output:
> > ======
> > <Swig Object of type 'Teuchos::RCP< Epetra_FECrsMatrix> *' at
> 0x9fb5140>
> > swig/python detected a memory leak of type 'Teuchos::RCP<
> Epetra_FECrsMatrix> *', no destructor found.
> >
> > ** Affects: dolfin
> > Importance: Undecided
> > Status: New
> >
>
> --
> You received this bug notification because you are a member of DOLFIN
> Team, which is subscribed to DOLFIN.
> https://bugs.launchpad.net/bugs/937724
>
> Title:
> Memory leak / unconverted smart pointers in down_cast().mat()
>
> Status in DOLFIN:
> New
>
> Bug description:
> A memory leak is reported when doing down_cast(A).mat() in python.
> Additionally, the smart-pointer object that is returned is not
> converted to a usable type. This is tested with trunk, I assume the
> same happens in 1.0. PETSc v3.2-p5, Trilinos v10.85.
>
> Test code:
> ========
> from dolfin import *
> dolfin.parameters["linear_algebra_backend"] = "Epetra" # also with PETSc
>
> mesh = UnitSquare(2,2)
> V = FunctionSpace(mesh, "CG", 1)
> v, u = TestFunction(V), TrialFunction(V)
> A = assemble(inner(grad(u),grad(v))*dx)
>
> C = down_cast(A).mat()
> print C
>
> Output:
> ======
> <Swig Object of type 'Teuchos::RCP< Epetra_FECrsMatrix > *' at 0x9fb5140>
> swig/python detected a memory leak of type 'Teuchos::RCP<
> Epetra_FECrsMatrix > *', no destructor found.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/dolfin/+bug/937724/+subscriptions
>

On 02/21/2012 01:13 PM, Joachim Haga wrote:
> That did the trick! I thought that explicitly importing PyTrilinos import
> was no longer needed with the recent(ish) MPI fixes in Trilinos.

There are no PyPETSc ATM. What with adding

   import PyTrilinos

inside EpetraFoo.foo(). Not that clean but then it is not imported
unless we need it.

Johan

> I'm thinking it would be nice if it weren't necessary... and if it didn't
> leak memory when PyTrilinos/PyPETSc isn't imported... but that's not vital
> right now.
>
> -j.
>
> On 21 February 2012 12:55, Johan Hake<email address hidden> wrote:
>
>> Have you imported PyTrilinos before you do the downcast for the Epetra
>> backend?
>>
>> Johan
>>
>> On 02/21/2012 12:45 PM, Joachim Haga wrote:
>>> Public bug reported:
>>>
>>> A memory leak is reported when doing down_cast(A).mat() in python.
>>> Additionally, the smart-pointer object that is returned is not converted
>>> to a usable type. This is tested with trunk, I assume the same happens
>>> in 1.0. PETSc v3.2-p5, Trilinos v10.85.
>>>
>>> Test code:
>>> ========
>>> from dolfin import *
>>> dolfin.parameters["linear_algebra_backend"] = "Epetra" # also with PETSc
>>>
>>> mesh = UnitSquare(2,2)
>>> V = FunctionSpace(mesh, "CG", 1)
>>> v, u = TestFunction(V), TrialFunction(V)
>>> A = assemble(inner(grad(u),grad(v))*dx)
>>>
>>> C = down_cast(A).mat()
>>> print C
>>>
>>> Output:
>>> ======
>>> <Swig Object of type 'Teuchos::RCP< Epetra_FECrsMatrix> *' at
>> 0x9fb5140>
>>> swig/python detected a memory leak of type 'Teuchos::RCP<
>> Epetra_FECrsMatrix> *', no destructor found.
>>>
>>> ** Affects: dolfin
>>> Importance: Undecided
>>> Status: New
>>>
>>
>> --
>> You received this bug notification because you are a member of DOLFIN
>> Team, which is subscribed to DOLFIN.
>> https://bugs.launchpad.net/bugs/937724
>>
>> Title:
>> Memory leak / unconverted smart pointers in down_cast().mat()
>>
>> Status in DOLFIN:
>> New
>>
>> Bug description:
>> A memory leak is reported when doing down_cast(A).mat() in python.
>> Additionally, the smart-pointer object that is returned is not
>> converted to a usable type. This is tested with trunk, I assume the
>> same happens in 1.0. PETSc v3.2-p5, Trilinos v10.85.
>>
>> Test code:
>> ========
>> from dolfin import *
>> dolfin.parameters["linear_algebra_backend"] = "Epetra" # also with PETSc
>>
>> mesh = UnitSquare(2,2)
>> V = FunctionSpace(mesh, "CG", 1)
>> v, u = TestFunction(V), TrialFunction(V)
>> A = assemble(inner(grad(u),grad(v))*dx)
>>
>> C = down_cast(A).mat()
>> print C
>>
>> Output:
>> ======
>> <Swig Object of type 'Teuchos::RCP< Epetra_FECrsMatrix> *' at 0x9fb5140>
>> swig/python detected a memory leak of type 'Teuchos::RCP<
>> Epetra_FECrsMatrix> *', no destructor found.
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/dolfin/+bug/937724/+subscriptions
>>
>

Trilinos uses its own smart pointer, which I expect why PyTrilinos must be imported.

On 21 February 2012 14:07, Garth Wells <email address hidden> wrote:

> Trilinos uses its own smart pointer, which I expect why PyTrilinos must
> be imported.

Yes, I added dolfin support for these a few months back, which is (part of)
the reason why I thought it should work. But it looks like it's only the
input typemaps.

Anyway, I think adding a try:import PyTrilinos in mat() and vec() in
la_post.i is a good idea, it would be very helpful for users. Maybe it's a
hack, but OTOH the return value from these is useless if PyTrilinos isn't
imported, and it won't do any harm (no import before it's needed, no
namespace pollution as long as it's done inside the function).

-j.

On 21 February 2012 13:59, Joachim Haga <email address hidden> wrote:
> On 21 February 2012 14:07, Garth Wells <email address hidden>
> wrote:
>
>> Trilinos uses its own smart pointer, which I expect why PyTrilinos must
>> be imported.
>
>
> Yes, I added dolfin support for these a few months back, which is (part of)
> the reason why I thought it should work. But it looks like it's only the
> input typemaps.
>
> Anyway, I think adding a try:import PyTrilinos in mat() and vec() in
> la_post.i is a good idea, it would be very helpful for users. Maybe it's a
> hack, but OTOH the return value from these is useless if PyTrilinos isn't
> imported, and it won't do any harm (no import before it's needed, no
> namespace pollution as long as it's done inside the function).
>

It seems logical to me that if a user wants to use PyTrilinos that
they should import it. I don't like the idea of importing it from
within DOLFIN.

Garth

> -j.
>
> --
> You received this bug notification because you are a member of DOLFIN
> Core Team, which is subscribed to DOLFIN.
> https://bugs.launchpad.net/bugs/937724
>
> Title:
>  Memory leak / unconverted smart pointers in down_cast().mat()
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/dolfin/+bug/937724/+subscriptions

Den 21. feb. 2012 20:50 skrev "Garth Wells" <email address hidden>
følgende:
>
> On 21 February 2012 13:59, Joachim Haga <email address hidden> wrote:

> > Anyway, I think adding a try:import PyTrilinos in mat() and vec() in
> > la_post.i is a good idea, it would be very helpful for users. Maybe
it's a
> > hack, but OTOH the return value from these is useless if PyTrilinos
isn't
> > imported, and it won't do any harm (no import before it's needed, no
> > namespace pollution as long as it's done inside the function).
> >
>
> It seems logical to me that if a user wants to use PyTrilinos that
> they should import it. I don't like the idea of importing it from
> within DOLFIN.

It's normally not required to import anything to be able to use returned
types. Import is only required to construct something by name. So I'd argue
that the logical thing is to return a valid and introspectable object. The
case where the errors were reported was a real-life one, not a constructed
example. I have put a work around in place in my code so that's OK, but I
still think "fixing" it on the dolfin side would be preferable when it's so
simple.

-j.

On 02/21/2012 08:44 PM, Garth Wells wrote:
> On 21 February 2012 13:59, Joachim Haga<email address hidden> wrote:
>> On 21 February 2012 14:07, Garth Wells<email address hidden>
>> wrote:
>>
>>> Trilinos uses its own smart pointer, which I expect why PyTrilinos must
>>> be imported.
>>
>>
>> Yes, I added dolfin support for these a few months back, which is (part of)
>> the reason why I thought it should work. But it looks like it's only the
>> input typemaps.
>>
>> Anyway, I think adding a try:import PyTrilinos in mat() and vec() in
>> la_post.i is a good idea, it would be very helpful for users. Maybe it's a
>> hack, but OTOH the return value from these is useless if PyTrilinos isn't
>> imported, and it won't do any harm (no import before it's needed, no
>> namespace pollution as long as it's done inside the function).
>>
>
> It seems logical to me that if a user wants to use PyTrilinos that
> they should import it. I don't like the idea of importing it from
> within DOLFIN.

The only reason a user would call mat or vec on an EpetraFoo would be to
get the underlying PyTrilinos object. That can be handled within that
method without any collateral imports, by adding a try/execpt clause.

We can raise an error if PyTrilinos is not available.

Johan

> Garth
>
>> -j.
>>
>> --
>> You received this bug notification because you are a member of DOLFIN
>> Core Team, which is subscribed to DOLFIN.
>> https://bugs.launchpad.net/bugs/937724
>>
>> Title:
>> Memory leak / unconverted smart pointers in down_cast().mat()
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/dolfin/+bug/937724/+subscriptions
>