Weird image rating returned by IO slave?

Hi all,

(I was in two minds whether to put this through bugs.kde.org given it's a little obscure.)

Yesterday evening, digiKam 2 from the SVN started hanging for two minutes when switching to the People tags section at the left.  It turns out that:

ImagePropertiesTab::setRating(int rating)

...is being called with rating=4390960.  So, it was concatenating 4390960 star characters, and passing this to d->labelRating->setText(), which gave Qt the two-minute job of working out how to render that.

This rating came from an ImageInfo object that was created from an ImageListerRecord that was created in:

ImageAlbumModel::slotData(KIO::Job*, const QByteArray& data)

...from the data it was given.  I've checked the database, and there are no ratings greater than 5, and the imageId associated with that rating is bogus too.

At this point, I took a look at where the data was coming from - the IO slaves - and got a bit stuck, hence coming to the mailing list.  Any suggestion as to what might be happening?

As a temporary work-around, I patched my copy of setRating to set the label to ' e r r o r ' if the rating was greater than 5.  I haven't seen this on screen once yet, though if I put a breakpoint at this line it's definitely being used.  Does a similar patch need committing to the SVN? (maybe not setting a label at all if it's junk?)

Andrew

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

> ...from the data it was given.  I've checked the database, and there are no
> ratings greater than 5, and the imageId associated with that rating is
> bogus too.

Did you double check there's not an ioslave from 1.x in use?

To debug this, look at libs/database/imagelister.cpp.
listFaces(), calling listFromIdList(). This happens on the ioslave side, which
means you need to "make install", ensure all old slaves are dead (happens
after a few secs), run digikam and look for debug output in your ~/.xsession-
errors file.

As you see, it's a binary protocol, which has very few safety nets, but we
never had problems. For faces, an extra field is transmitted, (see
record.binaryFormat) which may be part of the problem here.

>
> As a temporary work-around, I patched my copy of setRating to set the label
> to ' e r r o r ' if the rating was greater than 5.  I haven't seen this on
> screen once yet, though if I put a breakpoint at this line it's definitely
> being used.  Does a similar patch need committing to the SVN? (maybe not
> setting a label at all if it's junk?)

If there is any need for something like qBound(RatingMin, rating, RatingMax),
then at the very source of the problem,
QDataStream& operator>>(QDataStream& ds, ImageListerRecord& record)
Still this is curing a single symptom, I would prefer to analyze and prevent
the whole problem.

Marcel
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

On Thu, Jan 27, 2011 at 3:59 PM, Marcel Wiesweg <[hidden email]> wrote:

Did you double check there's not an ioslave from 1.x in use?

Hats off, didn't think of that - sure enough, that fixed it.

Cheers,

Andrew

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

> > Did you double check there's not an ioslave from 1.x in use?
>
> Hats off, didn't think of that - sure enough, that fixed it.

Now that even you have been caught by this, I'm beginning to think we should
prevent such a problem to happen by sending a magic value at the start of
packages using the new protocol. The old protocol still unchanged.

Marcel
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel