Re: [Tracker] Fix for segfault

["Samuel Cormier-Iijima" <sciyoshi gmail com>]

By the way, ideally the g_return_if_fail functions should only be used
to check for e.g. NULL parameters to the function (since it will
create a warning message) For example, when searching for something
without any results, I get "assertion failed (row != NULL && row[0] !=
NULL)" etc. Some more helpful error messages might be better?

On 10/5/06, Jamie McCracken <jamiemcc blueyonder co uk> wrote:
> Marcus Fritzsch wrote:
> > On 10/5/06, Jamie McCracken <jamiemcc blueyonder co uk> wrote:
> >> Marcus Fritzsch wrote:
> >> > On 10/5/06, Jamie McCracken <jamiemcc blueyonder co uk> wrote:
> >> >> Marcus Fritzsch wrote:
> >> >> > Hello there.
> >> >> >
> >> >> > With the new tracker I always encountered a segfault with some db
> >> code.
> >> >> >
> >> >> >    tracker_db_get_field_def
> >> >> >
> >> >> > can return NULL but
> >> >> >
> >> >> >    tracker_metadata_is_date
> >> >> >
> >> >> > in src/trackerd/tracker-db.c:591 dereferences a field in this
> >> >> > structure w/o checking for NULL.
> >> >> >
> >> >> >
> >> >>
> >> >> thanks have fixed in cvs
> >> >
> >> > When thinking about it a second time --- is that behaviour really ok
> >> > that way? It does prevent the segfault, but it is not a 'sane'
> >> > behaviour i think. The exact log context from such an assertion
> >> > failure is the following:
> >>
> >> yes it is right beacuse it indicates a potentially serious bug in one of
> >> the new metadata extractors!
> >>
> >> The segfault or log message would only ever occur if one of the
> >> extractors was using an invalid metadata name - we need to track these
> >> down!
> >>
> >> Any idea what the mime of the image file was?
> >
> > These are all JPEGs --- I got this same error lot's of times as I can
> > see them now ;) I'll investigate this further.
>
> then check out the exif metadata extractor
> compare against metadata in  tracker/data/sqlite-tracker.sql (names may
> be case sensitive)
>
> >
> >> > ------snap------
> >> >
> >> > The really disturbing 'Invalid UTF-8' comes from a library call? From
> >> > the UTF-8 conversion? I have not looked in too deep with this, I am
> >> > not sure if this will cause some problems later on.
> >> >
> >> > So, the question is, are there any complications from this UTF-8
> >> > thing? Is this known to someone?
> >>
> >> all metadata should be converted to utf8 (from users locales) and
> >> failing that it must be discarded - this is something that needs to be
> >> added to the new extractors.
> >>
> >> Patches welcome for above two :)
> >
> > Lets see what I (and others ;o)) can do.
>
> great!
>
> --
> Mr Jamie McCracken
> http://jamiemcc.livejournal.com/
>
> _______________________________________________
> tracker-list mailing list
> tracker-list gnome org
> http://mail.gnome.org/mailman/listinfo/tracker-list