← Back to team overview

dolfin team mailing list archive

Re: Results of Valgrind on all demos

 



Martin Sandve Alnæs wrote:
2008/6/20 Garth N. Wells <gnw20@xxxxxxxxx>:

Dag Lindbo wrote:
Hello!

I attach a script that runs Valgrind (memcheck) on all C++ demos (based
on the one that just runs all demos). My suggestion is that this be
included in the testing procedure.

At present (on my machine) 17 of 31 demos result in a memory leak (!)
None of the demos produce a memory error.

Note that most, but not all, leaks are due to XML parsing. Are these
really leaks? It is impossible for vg to understand memory pools and
other exotic memory management that are not explicitly freed. Glib does
this in the GTS interface. Maybe libxml2 does something similar. In that
case, I can easily provide a suppression for xml2.

I took a look and fixed at least one leak, but a few others don't look
like leaks to me. Part of the problem is that I think we're using
pointers is some classes where std::vector would be more appropriate,
particularly in the mesh and dof map classes, which is a source of
potential leaks and makes ownership unclear.

Is there a reason that we use pointers for various arrays in the mesh
classes rather than std::vector?

I believe you cannot get the pointer to std::vector content?
(At least not safely and portable?)


In many cases, this isn't needed. Pointers have been used for privare arrays which are (re)sized at runtime and aren't passed around, e.g.

  uint* connections

in MeshConnectivity.

An alternative may be to use shared_ptr<real>,
if several classes are to use the same memory.

The main backsides are more template syntax
and no python support. The latest swig is supposed
to have support for using shared_ptr with python.

If you want to try shared_ptr for arrays, you need to
define an array deleter, I can dig up the code
if anyone's interested.


Smart pointers could be useful in some cases. Boost also provides some elaborate smart pointers.

Garth


Follow ups

References