[OSM-dev] Memory Leak

Tom Hughes tom at compton.nu
Mon May 28 11:47:31 BST 2007

In message <dd93c7e84e.tom at loxley.compton.nu>
          Tom Hughes <tom at compton.nu> wrote:

> I think I may have tracked down the memory leak - or at least one
> major memory in leak in XML generation anyway.
> As suspected it is in the libxml wrapper, and there are actually
> several problems, at least some of which I need to talk to the
> wrapper folks about to be sure of the best fix.
> I have managed to patch it enough to be able to run my local test
> case (generating 1000 GPX files with 1000 points each) in a stable
> memory footprint of 10Mb instead of the 750Mb peak that it was
> reaching before.

I've now found a second memory leak in the libxml wrapper that was
being triggered by the API but not by my original test program. The
second leak was easy to fix, and a patch for the libxml wrapper is
attached to ticket 482 (as libxml-leak2.patch).

I've also attached a patch (libxml-leak1.patch) for the first leak
which is a rather scarier patch as I wound up reworking the way that
the wrapper keeps track of the link between ruby objects and libxml
objects... It also changes the semantics of the wrapper a little but
seemingly not in a way that upsets the API at all.

With these patches applied I have been able to run a local server
and make API requests with the server staying with a stable resident
set size of around 210Mb or so.

It also appears to be valgrind clean as far as I can tell based on
watching a couple of API requests - there are still a few small C level
leaks identified by valgrind, which seem to be in ruby itself, but
these are probably not significant.


Tom Hughes (tom at compton.nu)

More information about the dev mailing list