Dag Lindbo wrote: >>>> The GTS interface >>>> is so weird and poorly documented I don't if the problem is in GTS or >>>> DOLFIN. I suspect GTS. >>> Ok, but why does not the memory test produce gts related complains from the >>> two other linux buildbots? >>> >> No idea. If you would like to punish yourself, try figuring out how >> construction/destruiction works in GTS! Anders and I discussed briefly >> the possibility of using CGAL in place of GTS in the future. >> > > GTS has the benefit of having a debian/ubuntu package available.
CGAL is also available as a package. A serious issue is that higher the level components of CGAL (which we would want ot use) have a restrictive license (QPL). Garth As far > as the memory leaking goes: > > a) There was a big leak in the GTS interface that was fixed back in > March last year (changeset: 3654, Sun Mar 02 09:05:37). Some discussion > preceded this between me, Anders and Johan J that was off-list, and > there was a thread started by Kristen K on 02/26/2008. A very similar > (the same?) leak reappeared somewhere during the autumn and was picked > up by Marc. > > b) Careful valgrinding was done on the GTS interface when the first fix > was submitted. VG triggered on suspected leaks inside GLib, namely the > memory slice allocator that is used by the linked lists (that are used > by GTS). It is essentially a memory pool that isn't finalized as VG > expects. More info here: > http://library.gnome.org/devel/glib/stable/glib-running.html > > VG produces more sensible output if one sets env G_SLICE always-malloc. Use > G_SLICE=always-malloc G_DEBUG=gc-friendly \ > valgrind --leak-check=full --show-reachable=yes \ > --leak-resolution=high --trace-children=yes --num-callers=20 -v\ > ./foo > > VG may still report some bytes still reachable, but this was independent > of the mesh size, usage pattern of IntersectionDetector etc. Precisely > this issue turns up in loads of other projects if you google for it (eg. > QT4). > > A typical use for the IntersectionDetector/GTSInterface is to evaluate a > discrete function at an arbitrary point in the grid. There were some > timing results posted in a thread from 03/18/2008. > > /Dag _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
