Re: [Tracker] PATCH: Fix segfault in tracker-ontologies (shows in tracker-miner-fs) when ontologies are missing

[Martyn Russell <martyn lanedo com>]

On 12/08/13 08:12, Jonatan Pålsson wrote:
> Hi!
>
> On 9 August 2013 16:40, Martyn Russell <martyn lanedo com> wrote:
> > On 08/08/13 16:27, Philip Van Hoof wrote:
> > > Ho Jonatan,
> >
> >
> > Hi Philip, Jonatan,
> >
> >
> > > I don't really agree with this approach. We should not 'just' check for
> > > NULL and let the software continue as if nothing happens. Invalid
> > > ontologies means that we can't go on. So abort() is probably the only
> > > sensible way out.
> >
> >
> > Yes, I agree. This is on the same level as corrupt database type errors, i.e
> > we can not operate at all without a minimal requirement. One of those
> > requirements is a fully functioning and properly existing ontology.
>
> I see. Hm. I have noticed that the store continues to run in other
> cases, such as when properties are not found (try changing
> nao:lastModified to nao:lastModifiedd), or when declaring new
> properties (probably the wrong terminology..) stemming from
> non-existing classes (try xsd:string a rdfs:Classs .).
>
> Perhaps some check should be performed when loading the ontologies to
> see that all is well? Is there a zero-acceptance policy on brokenness

There is a utility to check your ontology ...

  utils/ontology/ontology-validator

That's quite useful.

> in the ontologies? If so, I suppose it is easier to perform this
> check, and abort if anything at all is broken.

There is yes. We do have a lot of things in place to deal with ontology 
updates and migrations, etc. But this is changing the database schema 
and should be very carefully considered.

> Yes, I agree with you both. We shouldn't continue with broken
> ontologies. I noticed that the gvdb reader behaves the same (gives a
> NULL in the same location) when the gvdb files are corrupt. The header
> of the gvdb appears to be checked for corruption, but the contents are
> not checked in the same way. I modified the gvdb file on disk with a
> text editor and achieved the same behavior.
>
> I think it is not a bad idea to check for NULL here, alternatively
> perform some integrity check of the file. Would you accept a patch
> which replaces the warnings with g_error?

I think so yes :)
Thanks,

--
Regards,
Martyn

Founder & Director @ Lanedo GmbH.
http://www.linkedin.com/in/martynrussell