On Sun, Feb 08, 2009 at 09:11:55PM +0000, Garth N. Wells wrote: > > > Anders Logg wrote: > > On Sun, Feb 08, 2009 at 05:56:43PM +0000, Garth N. Wells wrote: > >> > >> mspieg wrote: > >>> On Feb 6, 2009, at 6:35 PM, Garth N. Wells wrote: > >>> > >>>> > >>>> mspieg wrote: > >>>>> Hi All, > >>>>> I'm playing with some characteristic based advection schemes in > >>>>> Dolfin (0.9.0) which require a large number of discrete Function > >>>>> evals. This seems to be leading to a large memory leak as the > >>>>> process grows considerably in size with every time-step. I've put > >>>>> together a small (badly written) program that demonstrates the > >>>>> problem which I've tried to isolate just to IntersectionDetector (and > >>>>> the underlying GTS). I suspect the problem is in GTS, but thought I > >>>>> would start with Dolfin support. Any thoughts/help greatly > >>>>> appreciated... > >>>> I recall that quite some time ago some memory leaks were fixed in the > >>>> DOLFIN GTS interface, but there remained some GTS problems. Have you > >>>> run valgrind? > >>> Thanks Garth, > >>> I've been developing on mac OSX 10.4 which valgrind doesn't support > >>> (yet ?). I can probably dig up a linux box and run valgrind (but if > >>> someone else can do it faster that would be great). Apple has an > >>> application MallocDebug, which I've started playing with, but it seems > >>> to be choking on some of the libraries. I'll let you know if I make any > >>> progress. If anyone else has some insight or can easily run valgrind on > >>> this code (assuming that it develops the same memory issues under Linux > >>> as MacOSX), that would be great. > >>> > >> I think that I've fixed the leak (using top to view the memory use, it > >> now remains constant). I ran valgrind on the original code and it didn't > >> pick anything up but there was definitely a leak. GTS has an odd > >> interface which I would say contributed to the DOLFIN-side leak. > >> > >> Garth > > > > Nice. I was just about to look into it. Yes, the interface is a bit > > strange. > > How did you work out how to use it? Is there any human-readable > documentation? I could only find the developer reference doc which is > extracted from the code.
This one I think: http://gts.sourceforge.net/reference/gts-bounding-boxes-trees.html#GTS-BB-TREE-DESTROY > While we're at it, I'm not sure the destructor is correct. > > I tried to figure out how to do it correctly and came up with > > > > gts_bb_tree_destroy(tree, true); > > > > The other option would be > > > > gts_bb_tree_destroy(tree, false); > > > > The former seems OK. I think so too, but it's a bit confusing. In GTSInterface::buildCellTree() we already call g_slist_free(bboxes); but I guess the earlier call to tree = gts_bb_tree_new(bboxes); will create/copy new bboxes to the tree that need to be deleted. And at the end of all calls to bboxes = g_slist_prepend(bboxes, createBox(*c)); the bboxes pointer will be set to something sensible (like the beginning of the list) so bboxes may be used in the calls to g_slist_free() and gts_bb_tree_new(). It does seems to work... -- Anders
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
