On Wed, Jun 18, 2008 at 05:56:02PM +0200, Anders Logg wrote: > 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.
Did you close the bug in Bugzilla? -- Anders
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
