dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Jun 23, 2008 at 08:32:10AM +0200, Dag Lindbo wrote:
> Anders Logg wrote:
> > On Fri, Jun 20, 2008 at 08:27:30AM +0100, Garth N. Wells wrote:
> >>
> >> 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?
> > 
> > Yes, the mesh implementation relies heavily on storing data in
> > contiguous arrays and working with offsets into those arrays.
> > 
> > I doubt that there are any serious memory leaks in the mesh classes.
> > All data is stored in MeshTopology and MeshGeometry and their
> > destructors should take care of cleaning up.
> > 
> 
> A similar case of libxml2 not cleaning up properly is discussed here:
> http://mail.gnome.org/archives/xml/2006-July/msg00185.html
> 
> The solution is to add a call to xmlCleanupParser()
> 
> As far as I can tell, this call is not made by DOLFIN either.
> 
> /Dag

I can't find any errors that seem to be caused by libxml2. In all
cases where I find libxml2, the problem seems to be in DOLFIN, for
example in MeshTopology::init():

at 0x4022F14: operator new[](unsigned) (vg_replace_malloc.c:268)
==23734==    by 0x4198B03: dolfin::MeshTopology::init(unsigned)
(MeshTopology.cpp:88)
==23734==    by 0x41B03F2: dolfin::MeshEditor::open(dolfin::Mesh&,
dolfin::CellType::Type, unsigned, unsigned) (MeshEditor.cp
p:45)
==23734==    by 0x414F6C4: dolfin::XMLMesh::readMesh(unsigned char
const*, unsigned char const**) (XMLMesh.cpp:198)
==23734==    by 0x414F980: dolfin::XMLMesh::startElement(unsigned char
const*, unsigned char const**) (XMLMesh.cpp:35)
==23734==    by 0x414555E: dolfin::sax_start_element(void*, unsigned
char const*, unsigned char const**) (XMLFile.cpp:661)
==23734==    by 0x42ED140: xmlParseStartTag (in
/usr/lib/libxml2.so.2.6.31)
==23734==    by 0x42F67D8: xmlParseElement (in
/usr/lib/libxml2.so.2.6.31)
==23734==    by 0x42F2644: xmlParseContent (in
/usr/lib/libxml2.so.2.6.31)
==23734==    by 0x42F691D: xmlParseElement (in
/usr/lib/libxml2.so.2.6.31)
==23734==    by 0x42F2644: xmlParseContent (in
/usr/lib/libxml2.so.2.6.31)
==23734==    by 0x42F691D: xmlParseElement (in
/usr/lib/libxml2.so.2.6.31)

Even so, there doesn't seem to be an error in MeshTopology. For
example, we allocate

  connectivity = new MeshConnectivity*[dim + 1];

on line 88, but then this is deleted in the destructor.

Garth: The array (matrix) connectivity in MeshTopology could very well
be replaced by use of Array< Array<MeshConnectivity*> > if you're up
for it.

-- 
Anders

Attachment: signature.asc
Description: Digital signature