[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 > /Dag > > ==32003== 8 bytes in 1 blocks are definitely lost in loss record 2 of 11 > ==32003== at 0x4023294: operator new(unsigned) (vg_replace_malloc.c:224) > ==32003== by 0x8080E1F: > UFC_StokesBilinearForm_dof_map_0::create_sub_dof_map(unsigned) const > (Stokes.h:6751) > ==32003== by 0x40E3DDB: dolfin::DofMap::extractDofMap(ufc::dof_map const&, > unsigned&, dolfin::Array<unsigned> const&) const (DofMap.cpp:132) > ==32003== by 0x40E3FF1: > dolfin::DofMap::extractDofMap(dolfin::Array<unsigned> const&, unsigned&) const > (DofMap.cpp:93) > ==32003== by 0x411032B: > dolfin::DiscreteFunction::DiscreteFunction(dolfin::SubFunction&) > (DiscreteFunction.cpp:94) > ==32003== by 0x4108A12: dolfin::Function::operator=(dolfin::SubFunction) > (Function.cpp:209) > ==32003== by 0x41F5405: dolfin::LinearPDE::solve(dolfin::Function&, > dolfin::Function&) (LinearPDE.cpp:110) > ==32003== by 0x80660A1: main (main.cpp:86) > > _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
