dolfin team mailing list archive

[Dag Lindbo <dag@xxxxxxxxxx>]

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

> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev