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
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
