dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Jun 18, 2008 at 04:48:26PM +0100, Garth N. Wells wrote:
> 
> 
> Garth N. Wells wrote:
> > 
> > bugzilla-daemon@xxxxxxxxxx wrote:
> >> http://www.fenics.org/cgi-bin/bugzilla/show_bug.cgi?id=40
> >>
> >>            Summary: Memory leaked after (sub) DofMap extraction
> >>            Product: DOLFIN
> >>            Version: development version
> >>           Platform: PC
> >>         OS/Version: Linux
> >>             Status: NEW
> >>           Severity: blocker
> >>           Priority: P2
> >>          Component: general
> >>         AssignedTo: dolfin-dev@xxxxxxxxxx
> >>         ReportedBy: dag@xxxxxxxxxx
> >>
> >>
> >> This leak is seen eg. in the Stokes demo using Valgrind. It originates from
> >> where sub functions are extracted and appears to be a sub_dof_map not freed on
> >> line 132 of DofMap.cpp. This is in an area of Dolfin where I'm not familiar
> >> enough to suggest a fix.
> >>
> > 
> > The problem is that both DofMap and BoundaryCondition::LocalData call
> > 
> >    DofMap* DofMap::extractDofMap(...)
> > 
> > but don't assume responsibility for the data and clean up in the destructor.
> > 
> > I'm looking at a solution, but I'm running into some problems that I 
> > don't yet understand.
> > 
> > Garth
> > 
> 
> I've fixed the memory leaks, but it was hard to follow the code in 
> DofMap, and the fix in DofMap.cpp is not entirely satisfying. Some 
> functions return pointers to data that they create but then it's often 
> not clear who owns the data. Perhaps DofMap should own all sub-DofMaps 
> of it and be responsible for cleaning them all up? If a sub-DofMap is 
> needed, DofMap can be asked for a reference to it. This would also 
> simplify any re-ordering of the DofMap.
> 
> Garth

Yes. It's a bit of a mess. We can fix this when we redesign DofMapSet.

-- 
Anders

Attachment: signature.asc
Description: Digital signature