Re: [Tracker] Some memory leaks

[Jürg Billeter <j bitron ch>]

On Tue, 2009-08-11 at 21:00 +0300, Martyn Russell wrote:
> On 08/08/09 03:24, Tuukka Hastrup wrote:
> > I did some testing on Tracker 0.7 head and hit some memory leaks. With
> > valgrind memcheck and massif, I've spotted two problems in the code, but
> > I don't think I can fix them with my current experience:
>
> Yea, same here recently. Thanks for taking the time to do this!

Sorry for the late response, I forgot again about this mail.

> > 1. Unreachable memory according to memcheck
> >
> > The source is this statement at
> > src/libtracker-data/tracker-sparql-query.vala:
> > foreach (Property prop in Ontology.get_properties ())
> >
> > The result of the following call is never freed at
> > src/libtracker-data/tracker-sparql-query.c:
> > tracker_ontology_get_properties ();
> >
> > This is given in src/libtracker-common/libtracker-common.vapi as:
> > [CCode (array_length = false, array_null_terminated = true)]
> > public weak Property[] get_properties ();
> >
> > The implementation at src/libtracker-common/tracker-ontology.c does:
> > return g_memdup (properties->data, sizeof (TrackerProperty *) *
> > (properties->len + 1));
>
> This looks similar to the tracker-sparql-query.vala bug with 
> get_namespace leak I found recently on line ~314
>
> If this is the same thing, it is a known problem and a Vala bug.
> It is on our roadmap to be fixed by Jurg:

Fixed now by changing the implementation, the allocation was unneeded.

> > 2. Quickly growing heap usage according to massif
> >
> > I noticed that tracker-storage began to grow a few megabytes per second
> > while running this in shell:
> > src/tracker-utils/tracker-sparql -q "SELECT * WHERE { ?p rdf:type
> > nie:InformationElement . }" |xargs -l1 src/tracker-utils/tracker-info
> >
> > I learned on IRC that it's a known problem that the cache
> > TrackerDBInterfaceSqlitePrivate.dynamic_statements keeps growing, and
> > shrinking it isn't implemented yet. I still wonder if these long queries
> > by tracker-info should actually be cached as a single query, as the only
> > part of the query changing is one constant (repeated in many places in
> > the query though): e.g. "WHERE ID = 683" vs. "WHERE ID = 777".
>
> Jurg, any idea about this one?

This should have been "WHERE ID = ?", thanks for reporting. I've
committed a fix for this a few weeks ago.

JÃrg