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
