[Tracker] Some memory leaks




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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]