[Tracker] Some memory leaks

[Tuukka Hastrup <Tuukka Hastrup iki fi>]

Hi all!

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:


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));

Should the implementation change, or the vapi definition, or the vala 
code, and how?


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".


Regards,
Tuukka