Anders Logg wrote:
> 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 <[EMAIL PROTECTED]>:
>>>> 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); }
>
>
OK.
It seems that the cleaning up in the mesh classes is too clever for
valgrind because I couldn't spot any leaks.
Garth
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> DOLFIN-dev mailing list
> [email protected]
> http://www.fenics.org/mailman/listinfo/dolfin-dev
_______________________________________________
DOLFIN-dev mailing list
[email protected]
http://www.fenics.org/mailman/listinfo/dolfin-dev
