Re: [Tracker] REVIEW: Fix Deprecations Branch

[Philip Van Hoof <philip codeminded be>]

On Fri, 2013-09-06 at 13:53 +0200, Jonatan Pålsson wrote:
> Hi Martyn!
>
> On 6 September 2013 13:36, Martyn Russell <martyn lanedo com> wrote:
> > On 06/09/13 10:01, Jonatan Pålsson wrote:

[cut]

> I have a feeling that the "ontologies.gvdb" file influences the
> behavior I observed. This may have been my imagination however. This
> file is not removed by the tracker-control -r command. By the way, is
> this intended, or is tracker-control -r supposed to remove the gvdb
> file as well? The manual says -r will remove *databases* - which it
> indeed does, but the gvdb file?

The ontologies.gvdb file is needed to detect ontology changes. It's not
a database with content except for the most current ontology (which is
meta information). Although if there's no content then no ontology
changes must ever happen, of course. This, however, depends on the
existence of backups by the user (a user can restore a backup and gain
content databases that way).


> As a side note, the tracker-store.ontology.journal file also survives
> "tracker-control -r", is this also the intended behavior? Otherwise I
> might write up a patch for removing these two files.

Same explanation.

Perhaps we can remove these files on tracker-control -r (or add another
flag that does this), but I'd rather await Jürg's input on this as I
remember we concluded that there are use-cases for which the files must
not be removed.

> > > /usr/local/libexec/tracker-store
> > >
> > > After these commands, the store should segfault.
> > >
> > > Also, perhaps related to the crashes;
> > > - on line 963 of tracker-data-update.c , should GValueArray actually
> > > be a GArray? I believe resource_buffer->predicates is a GArray
> > > already, but is assigned the wrong type here. (see line 1371)

Read deprecation note here:

https://developer.gnome.org/gobject/stable/gobject-Value-arrays.html#g-value-array-new

And compare with this API:

https://developer.gnome.org/glib/unstable/glib-Arrays.html#g-array-sized-new

And then look at line 1375

old_values = g_array_sized_new (FALSE, TRUE, sizeof (GValue),
        multiple_values ? 4 : 1);

Notes on GValueArray:

The prime purpose of a GValueArray is for it to be used as an object
property that holds an array of values. A GValueArray wraps an array
of GValueelements in order for it to be used as a boxed type
through G_TYPE_VALUE_ARRAY.

GValueArray is deprecated in favour of GArray since GLib 2.32. It is
possible to create a GArray that behaves like a GValueArray by using the
size ofGValue as the element size, and by setting g_value_unset() as the
clear function using g_array_set_clear_func(), for instance, the
following code:

                                   1
GValueArray *array = g_value_array_new (10);
can be replaced by:

                                   1
                                   2
GArray *array = g_array_sized_new (FALSE, TRUE, sizeof (GValue), 10);
g_array_set_clear_func (array, (GDestroyNotify) g_value_unset);


I'm idd not entirely sure whether the GLib team also ensures
compatibility with the GVAlueArray struct, though.


> > Great that you noticed this. Did fixing this fix the crashing for you?
> > I would accept patches to that branch if you've got the time.
>
> Unfortunately it did not :( I did however get different segfaults, so
> it appears to have fixed one of the issues. I may have time to push
> some to this branch, but I would like to solve all the segfaults first
> (locally on my machine), to ensure the patches are good.




-- 
Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be