On Wed, Jun 18, 2008 at 04:48:26PM +0100, Garth N. Wells wrote: > > > Garth N. Wells wrote: > > > > [EMAIL PROTECTED] 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: [email protected] > >> ReportedBy: [EMAIL PROTECTED] > >> > >> > >> 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
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
