Bug 303843

Same here, also 4:4.8.90-0ubuntu1 ubuntu quantal; Okular identifies itself as 0.14.90 , using KDE Development Platform 4.8.90 (4.8.90)

Just keeps spinning the rotating progress icon, never finishes, even on a couple of page doc.

Please, attach a document with such a problem.

Created attachment 72647 [details]
www.kde.org/.../QtContributionLicenseAgreement-1-1.pdf

Try searching for anything in this (It's just the Contribution agreement of kde.org for qt); e.g.

ctrl-f
Agreement

never stops, shows feedback or anything.

Works like a charm here, any change you can try with rc1 or rc2?

Still seems to happen for me with okular 0.15.70 on kde 4.8.97 (that I think is rc2) using the project-neon package build 2+git20120721+r4029-1~quantal1; this run is in a 32bit KVM guest, as opposed to my original run on 64bit host; so it's not word size or graphics card dependent.

okular 0.15.70 is not rc2, if your package for rc2 contains that, tell your packager, rc2 is okular 0.14.97

OK, thanks - I don't have access to a specific rc2 set of .deb's - although if you have pointers I'd be interested.

Having said that, given that I'm able to recreate this on 0.14.90 prior to the rc's, and you're saying the 0.15.70 is after the rc's it would be surprising if it had been fixed just for the rc version.

(I probably won't have a chance to do another test until next weekend).

Well, it works for me as i said in rc2

I'm not an ubuntu packager, the only thing i can say is you can try building from source tarball of the rc2 packages if you know how to do that.

Adding the kubuntu packagers so they can see the fact that they decided to pckage rc2 is hurting our users

Albert:
  I've added an Ubuntu bug ( https://bugs.launchpad.net/ubuntu/+source/okular/+bug/1027657 )
that links back to this one so it can be tracked.

I think the only reason rc2 isn't packaged was a lack of resource.

Of course it's not obvious that it would work in rc2 either and it might be something more subtle.

One thing I hadn't previosly noticed (and don't know if is relevant); if I start okular on the command line and do the search I see:


QMetaObject::invokeMethod: No such method Okular::Document::doContinueNextMatchSearch(void *,void *,int,int,QString,int,bool,QColor,bool)

(both on the older and newer version I tried).

Yes, this is very important.

Anyway i've confirmed with ubuntu developers that precise+okular from project neon can search and that quantal+okular from project neon can not search so it is a downstream (aka Ubuntu issue) and they'll have to deal with it since there's nothing i can fix in Okular itself

Ok thanks Albert.

Thanks for caring about Okular, let's hope the kubuntu devels can find a fix soon.

*** Bug 303933 has been marked as a duplicate of this bug. ***

Rex, adding you since the duplicated 303933 affects fedora too, maybe you guys share some bad patch in Qt or gcc? People have confirmed it works fine in Arch gcc 4.7 and Qt 4.8.2

I can't reproduce on my own f17/x86_64 box (ie, it searches pdf's just fine).  Is there a chance of a missing builld or runtime dependency or is okular just using facilities directly from poppler here?

No poppler, it's just okular code.

The
QMetaObject::invokeMethod: No such method Okular::Document::doContinueNextMatchSearch(void *,void *,int,int,QString,int,bool,QColor,bool)
means something was very wrong on compilation/execution since that is never invoked, what is invoked is Okular::Document::doContinueNextMatchSearch(void *,void *,int,int,QString,int,bool,QColor,bool,int) in lines 1224 and 2956 of document.cpp so there is something wrong somewhere, i'd blame either gcc or qt, but to be honest i have no clue

This bug has hitted qt4-x11/4:4.8.2-2 but no qt4-x11/4:4.8.2-1. Apart from the patches between them (two very small and contained), the only difference seems to be GCC.

I'm currently rebuilding qt4-x11/4:4.8.2-1 with current GCC to see if it gets triggered.

Tracking downstream @ 
https://bugzilla.redhat.com/show_bug.cgi?id=846847

fedora users,  please  followup there.

(In reply to comment #19)
> This bug has hitted qt4-x11/4:4.8.2-2 but no qt4-x11/4:4.8.2-1. Apart from
> the patches between them (two very small and contained), the only difference
> seems to be GCC.

I forgot to mention that this is Debian ;)

The Debian bug is in <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684177>

GCC is also the main difference between Fedora 17 and 18 (gcc-4.7.0-5.fc17 vs. gcc-4.7.1-5.fc18). So it may well be a regression in GCC.

Indeed, qt4-x11/4:4.8.2-1 was compiled with gcc-4.7.0-1 and qt4-x11/4:4.8.2-2 with gcc-4.7.1-2 (both Debian revisions).

The problem is clearly a gcc bug. It has gone with version 4.7.1-6 currently in Debian Sid, you may want to look for patches there, although the correct one could be between versions -2 and -6 inclusive.

Kinds regards, Lisandro.

Good work :-)

Is any of you guys reporting this upstream to gcc?

(In reply to comment #25)
> Is any of you guys reporting this upstream to gcc?

I haven't spotted the right patch in gcc (nor I tried, to be honest). In other words, I don't have a clue what could have possibly changed.

Well, but we have confirmed it's a gcc regression, no?

We can tell them and maybe they can find faster?

Comment #24 implies this is already fixed in current GCC, at least in Debian, but it probably got fixed by something from the GCC 4.7 branch. So I'm not sure reporting it to upstream GCC is useful.

Oh, i can't read, i thought he had gone back in versions, not forward, ignore my suggestion then