dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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

Attachment: signature.asc
Description: Digital signature