On Fri, Jun 20, 2008 at 09:09:19AM +0100, Garth N. Wells wrote:
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.
Yes, it's passed around. See for example operator() in MeshConnectivity:
inline const uint* operator() (uint entity) const
{ return (entity < num_entities ? connections + offsets[entity] : 0); }
