Discussion:
okular problem
Add Reply
John Forkosh
2020-02-06 11:58:00 UTC
Reply
Permalink
Problem is ... it stopped working. In particular, it opens
a pdf file just fine, but after scrolling through just a few
pages, it completely hangs/freezes, and I have to kill the
process. djvu files work just fine, no problem at all.
Only pdf files hang.

Google gives just a handful of similar problems over the
past several years, and no solutions that seem applicable,
as far as I can tell. I tried rm'ing all the okular stuff
under .kde/, but no luck. And then I tried reinstalling from
my slackware64/kde/okular-4.14.3-x86_64-3.txz file,
first using upgradepkg, and when that didn't change anything
removepkg and installpkg, but that didn't help either.

My slackware is -current64 downloaded 01Sep2019. And okular
had been working fine till just about a week ago. Then "poof".
I'd say that I didn't change anything or do anything, but
that's presumably somehow mistaken. Anybody have any similar
experience, or any suggestion about identifying/fixing the
problem?
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
Aragorn
2020-02-06 12:48:11 UTC
Reply
Permalink
Post by John Forkosh
Problem is ... it stopped working. In particular, it opens
a pdf file just fine, but after scrolling through just a few
pages, it completely hangs/freezes, and I have to kill the
process. djvu files work just fine, no problem at all.
Only pdf files hang.
Google gives just a handful of similar problems over the
past several years, and no solutions that seem applicable,
as far as I can tell. I tried rm'ing all the okular stuff
under .kde/, but no luck. And then I tried reinstalling from
my slackware64/kde/okular-4.14.3-x86_64-3.txz file,
first using upgradepkg, and when that didn't change anything
removepkg and installpkg, but that didn't help either.
My slackware is -current64 downloaded 01Sep2019. And okular
had been working fine till just about a week ago. Then "poof".
I'd say that I didn't change anything or do anything, but
that's presumably somehow mistaken. Anybody have any similar
experience, or any suggestion about identifying/fixing the
problem?
You're not going to like the answer, though. Slackware — current or
otherwise — is still using KDE Plasma 4, and for that matter, several
major versions behind the last of the KDE 4.x releases.

The very last KDE Plasma of the 4.x generation was 4.14.18, which has already
been deprecated for several years. Upstream is now preparing for the
release of Plasma 5.18 LTS, and the current stable release is Plasma
5.17.5, with KDE Frameworks 5.66.0, built upon Qt 5.14.0. Okular's
current stable version is 1.9.1.

If Okular is important for your workflow and you can't find anything
with the same functionality from Slackware's offering of GTK-based PDF
readers or even plain old xpdf, then I would suggest trading in
Slackware for a more up-to-date distribution. And if systemd is what's
holding you back from adopting another distribution, then I can assure
you that there are still plenty of distributions that either use
sysvinit or another such init system — e.g. openrc, runit, Upstart, et
al.

The choice, of course, is yours. ;)
--
With respect,
= Aragorn =
John Forkosh
2020-02-07 00:41:45 UTC
Reply
Permalink
Post by John Forkosh
Problem is ... it stopped working. In particular, it opens
a pdf file just fine, but after scrolling through just a few
pages, it completely hangs/freezes, and I have to kill the
process. djvu files work just fine, no problem at all.
Only pdf files hang.
Google gives just a handful of similar problems over the
past several years, and no solutions that seem applicable,
as far as I can tell. I tried rm'ing all the okular stuff
under .kde/, but no luck. And then I tried reinstalling from
my slackware64/kde/okular-4.14.3-x86_64-3.txz file,
first using upgradepkg, and when that didn't change anything
removepkg and installpkg, but that didn't help either.
My slackware is -current64 downloaded 01Sep2019. And okular
had been working fine till just about a week ago. Then "poof".
I'd say that I didn't change anything or do anything, but
that's presumably somehow mistaken. Anybody have any similar
experience, or any suggestion about identifying/fixing the
problem?
You're not going to like the answer, though. Slackware ??? current
or otherwise ??? is still using KDE Plasma 4, and for that matter,
several major versions behind the last of the KDE 4.x releases.
The very last KDE Plasma of the 4.x generation was 4.14.18, which has
already been deprecated for several years. Upstream is now preparing
for the release of Plasma 5.18 LTS, and the current stable release is
Plasma 5.17.5, with KDE Frameworks 5.66.0, built upon Qt 5.14.0.
Okular's current stable version is 1.9.1.
If Okular is important for your workflow and you can't find anything
with the same functionality from Slackware's offering of GTK-based
PDF readers or even plain old xpdf, then I would suggest trading in
Slackware for a more up-to-date distribution. And if systemd is what's
holding you back from adopting another distribution, then I can assure
you that there are still plenty of distributions that either use
sysvinit or another such init system ??? e.g. openrc, runit, Upstart,
et al.
Thanks, Aragorn. Yeah, I also use acroread (with multilib
also installed) and xpdf and gv. So no overwhelming problem
accessing pdf info. But okular's my preference if available,
which it usually is. And your remarks don't seem to explain
why it had been working perfectly for pdf's, and still is for
djvu's.

Moreover, I have three other boxes with the identical
slackware, all installed from the same usb stick, and okular
continues reading pdf's just fine on all those other boxes.
So I'm still pretty convinced that something-or-other got
corrupted/messed-up/whatever, probably by something I did,
but am clueless what that might be.

Ultimately, I have several spare partitions on this box,
and can install a test version of the same slackware from
the same usb stick on this same box, and double-check that
okular works on a fresh install.
The choice, of course, is yours. ;)
Isn't that what the passengers were told
by the captain of the Titanic?
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
Aragorn
2020-02-07 07:24:32 UTC
Reply
Permalink
Post by John Forkosh
Post by Aragorn
The very last KDE Plasma of the 4.x generation was 4.14.18, which
has already been deprecated for several years. Upstream is now
preparing for the release of Plasma 5.18 LTS, and the current
stable release is Plasma 5.17.5, with KDE Frameworks 5.66.0, built
upon Qt 5.14.0. Okular's current stable version is 1.9.1.
If Okular is important for your workflow and you can't find anything
with the same functionality from Slackware's offering of GTK-based
PDF readers or even plain old xpdf, then I would suggest trading in
Slackware for a more up-to-date distribution. And if systemd is
what's holding you back from adopting another distribution, then I
can assure you that there are still plenty of distributions that
either use sysvinit or another such init system ??? e.g. openrc,
runit, Upstart, et al.
Thanks, Aragorn. Yeah, I also use acroread (with multilib
also installed) and xpdf and gv. So no overwhelming problem
accessing pdf info. But okular's my preference if available,
which it usually is. And your remarks don't seem to explain
why it had been working perfectly for pdf's, and still is for
djvu's.
My recollection of how things were organized in the days of KDE 4.x is
a bit troubled, but I remember that there was a cache directory for
every user who ever ran KDE, and in most distributions, this
directory was usually located under /var/tmp.

Periodically erasing this directory before starting X (or logging in
via a display manager) seemed to cure some application-level
inconsistencies — the directory gets recreated automatically upon the
next start of KDE Plasma 4.x. It's only cache data, so nothing of
importance would get lost by deleting it.

(Plasma 5.x stores its cache data under ${HOME}/.cache.)
Post by John Forkosh
Post by Aragorn
The choice, of course, is yours. ;)
Isn't that what the passengers were told by the captain of the Titanic?
Dunno, that was before my time. :p
--
With respect,
= Aragorn =
John Forkosh
2020-02-08 05:19:56 UTC
Reply
Permalink
Aragorn <***@telenet.be> wrote:
<snip>
Post by Aragorn
My recollection of how things were organized in the days of KDE 4.x is
a bit troubled, but I remember that there was a cache directory for
every user who ever ran KDE, and in most distributions, this
directory was usually located under /var/tmp.
Periodically erasing this directory before starting X (or logging in
via a display manager) seemed to cure some application-level
inconsistencies ??? the directory gets recreated automatically upon the
next start of KDE Plasma 4.x. It's only cache data, so nothing of
importance would get lost by deleting it.
(Plasma 5.x stores its cache data under ${HOME}/.cache.)
Thanks again, Aragorn. I hadn't thought to try that (was aware of
~/.cache and of ~/.kde and various others), and didn't even know
about /var/tmp/. Tried emptying them all and rebooting, but
had no effect on okular's bad behavior.

But see Henrik's post and my followup: kill'ing the cupsd daemon
process immediately cleared up the okular problem (no reboot
necessary, didn't even have to re-start X). So now the remaining
problem is to figure out what/why and how to fix it, so that they
can peacefully co-exist.
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
Jimmy Johnson
2020-02-06 15:31:55 UTC
Reply
Permalink
Post by John Forkosh
Problem is ... it stopped working. In particular, it opens
a pdf file just fine, but after scrolling through just a few
pages, it completely hangs/freezes, and I have to kill the
process. djvu files work just fine, no problem at all.
Only pdf files hang.
Google gives just a handful of similar problems over the
past several years, and no solutions that seem applicable,
as far as I can tell. I tried rm'ing all the okular stuff
under .kde/, but no luck. And then I tried reinstalling from
my slackware64/kde/okular-4.14.3-x86_64-3.txz file,
first using upgradepkg, and when that didn't change anything
removepkg and installpkg, but that didn't help either.
My slackware is -current64 downloaded 01Sep2019. And okular
had been working fine till just about a week ago. Then "poof".
I'd say that I didn't change anything or do anything, but
that's presumably somehow mistaken. Anybody have any similar
experience, or any suggestion about identifying/fixing the
problem?
Hi John sorry to hear of your problem. I can't reproduce it. I tried
using a large pdf(harry potter vol.7 in pdf), but no problem, before and
after updating on 2 machines and still no problem.
Start okular as user from the console and tell us what errors you get
when you get the errors. Also you can try and open pdf using xpdf it's
also installed.
--
Jimmy Johnson

Slackware64 Current - KDE 4.14.38 - EXT4 at sda5
Registered Linux User #380263
John Forkosh
2020-02-07 00:53:26 UTC
Reply
Permalink
Post by Jimmy Johnson
Post by John Forkosh
Problem is ... it stopped working. In particular, it opens
a pdf file just fine, but after scrolling through just a few
pages, it completely hangs/freezes, and I have to kill the
process. djvu files work just fine, no problem at all.
Only pdf files hang.
Google gives just a handful of similar problems over the
past several years, and no solutions that seem applicable,
as far as I can tell. I tried rm'ing all the okular stuff
under .kde/, but no luck. And then I tried reinstalling from
my slackware64/kde/okular-4.14.3-x86_64-3.txz file,
first using upgradepkg, and when that didn't change anything
removepkg and installpkg, but that didn't help either.
My slackware is -current64 downloaded 01Sep2019. And okular
had been working fine till just about a week ago. Then "poof".
I'd say that I didn't change anything or do anything, but
that's presumably somehow mistaken. Anybody have any similar
experience, or any suggestion about identifying/fixing the
problem?
Hi John sorry to hear of your problem.
Thanks, Jimmy. Not to worry, I only wish this were the worst
problem I had to deal with:)
Post by Jimmy Johnson
I can't reproduce it. I tried using a large pdf (harry potter
vol.7 in pdf), but no problem, before and after updating on 2
machines and still no problem.
Yeah, I have three other boxes with the identical slackware
installed, and also can't reproduce the problem on any other box.
Something-or-other must have gotten corrupted/messed-up/whatever,
probably by something I did on this box, but I have no idea what
that might be. And that's what I'm trying to identify (and fix).
Post by Jimmy Johnson
Start okular as user from the console and tell us what errors
you get when you get the errors. Also you can try and open pdf
using xpdf it's also installed.
I usually do start okular from a /usr/bin/konsole terminal window.
No errors at all. The okular window just freezes/hangs after a
few pages of scrolling through any pdf (large or small). And
the terminal window shows no messages. Zilch. Nada.
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
John Forkosh
2020-02-07 01:26:08 UTC
Reply
Permalink
<snip>
Post by John Forkosh
Post by Jimmy Johnson
Start okular as user from the console and tell us what errors
you get when you get the errors. Also you can try and open pdf
using xpdf it's also installed.
I usually do start okular from a /usr/bin/konsole terminal window.
No errors at all. The okular window just freezes/hangs after a
few pages of scrolling through any pdf (large or small).
Okay, just to be sure, I tried >>really<< small, a two-page pdf.
And that does work fine. Scrolls back-and-forth-and-back-and...
without any problem/complaint/hiccup/etc. Just works. And then,
after a little further testing, seems like ~9pages is the limit,
though I can't tell (without further testing) whether that's
filesize in bytes or #pages (or maybe something else entirely).
For example, after seeing that "pdf limit" I checked my swap
space, which is fine, although with 16GB memory (and free showing
15.5GB available) okular isn't likely to be trying to access it.
Post by John Forkosh
And the terminal window shows no messages. Zilch. Nada.
Just to be clear, I do get what seems to be okular's usual
messages... several lines of the form
okular(1502)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
on the terminal window. But that's what has always happened
running okular (at least for me). And there are no further
messages whatsoever when it hangs.
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
Rudolf Mueller
2020-02-07 11:24:58 UTC
Reply
Permalink
I have this problem too.
For me, it seems to be a problem, who has the pdf created or with which tool.
Many make the problem at about +/- 10 pages, I can open it with a new okular-session
starting with the last page which was ok until it freezes again an so on.
Otherwise i can open pdfs with some hundred pages and have no problem at all ...
And it makes no difference, if I access the pages by the preview slider or paging down
in the content. The number of pages seems to be constant for a given pdf which causes the error.

Regards ;)
John Forkosh
2020-02-08 04:04:00 UTC
Reply
Permalink
Post by Rudolf Mueller
I have this problem too.
Terrific. Misery loves company :)
Post by Rudolf Mueller
For me, it seems to be a problem, who has the pdf created
or with which tool. Many make the problem at about +/- 10 pages,
I can open it with a new okular-session starting with the
last page which was ok until it freezes again an so on.
Otherwise i can open pdfs with some hundred pages and have
no problem at all ...
And it makes no difference, if I access the pages by the
preview slider or paging down in the content. The number of
pages seems to be constant for a given pdf which causes the error.
Regards ;)
Thanks, Rudolf. And we're apparently having precisely the same
problem, because you're absolutely right, and my original post
was wrong -- some files do work absolutely fine. In particular,
(a) my own .tex source files "compiled" with pdflatex work fine,
(b) that prompted me to try some arxiv.org pdf files, which
all also work fine,
(c) scanner files saved as pdf work fine.
And I suppose some others, but that's all I tested.

What seems to be failing is each and every full-length book
downloaded from the web. As a particular example,
https://www.springer.com/gp/book/9783319517766
(which I chose as an example because it's a Springer open-access
book, freely/legally downloadable from that url -- and, of course,
because it exhibits the problem)

Then I strace'd several working-versus-failing pdfs. And the
difference in every single case is that the failing pdfs
always read/re-read/re-re-read/etc a printer ppd file,
as discussed at length in preceding strace posts. And the working
pdfs never do that. And, by the way, referring to those strace posts,
the failing pdfs always hang at the same fd=120. That prompted me to
run lsof against hung processes, but they all have ~300 open files,
well below the linux default limit of 1024.

Anyway, I did get some very, very goofy fix to work: using the
example book above, I used pdfjam to make a "copy"
pdfjam Foundations_of_Quantum_Theory.pdf 1-881 -o test.pdf
of all 881 pages in the book, And the copy's about 1MB smaller,
7593084 Feb 5 2019 Foundations_of_Quantum_Theory.pdf
6595838 Feb 7 22:22 test.pdf
Moreover, okular now scrolls through that copy just fine.
No problem, no hang/freeze, nothing bad whatsoever.
Go figure.

So, Rudolf, just as a verifying test, if you have a few minutes,
please download that book, verify that it hangs under okular,
and that a pdfjam copy runs fine. I think our duplicate experience
should be pretty reasonable evidence of some kind of actual problem
(precisely what kind of problem still to be determined).
Thanks again, and please follow-up with your results
if you do the test,
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
Rudolf Mueller
2020-02-08 19:53:46 UTC
Reply
Permalink
The link did not work for me but I could get (by google-search ;)
2017_Book_FoundationsOfQuantumTheory.pdf
(seems to be this book)

Same effect as you. okular stuck after page 11, after conversion
no glitches.
Rudolf Mueller
2020-02-08 20:05:51 UTC
Reply
Permalink
Post by Rudolf Mueller
The link did not work for me but I could get (by google-search ;)
2017_Book_FoundationsOfQuantumTheory.pdf
(seems to be this book)
Same effect as you. okular stuck after page 11, after conversion
no glitches.
/etc/rc.d/rc.cups stop
okular /tmp/2017_Book_FoundationsOfQuantumTheory.pdf
without glitches :)

That seems too be an explanation for oddities I had with printing
PDFs from okular:
first print pdf in okular ok,
print it again for second copy --> okular hangs

I'm not sure, if this were problematic PDFs or normal, but I think
it appeared to be the case for any of them.
John Forkosh
2020-02-10 10:54:48 UTC
Reply
Permalink
Post by Rudolf Mueller
Post by Rudolf Mueller
The link did not work for me
That's odd. You'd think Springer would be deutschland-friendly
(have Trump and Merkel gotten into some sort of pissing contest
lately?:) Anyway, besides that .../gp/... site, Springer has
a dedicated us site
https://www.springer.com/us/book/9783319517766
and both links work identically for me (and both show English
content from my New York City location).
Post by Rudolf Mueller
Post by Rudolf Mueller
but I could get (by google-search ;)
2017_Book_FoundationsOfQuantumTheory.pdf
(seems to be this book)
Same effect as you. okular stuck after page 11, after conversion
no glitches.
/etc/rc.d/rc.cups stop
okular /tmp/2017_Book_FoundationsOfQuantumTheory.pdf
without glitches :)
Okay, great. I'd only suggested "kill pid" because I wasn't
sure you were using slackware. Since you are, what versions
of okular and cups are you running? I'm using
slackware-current64/slackware/kde/okular-4.14.3-x86_64-3.txz
slackware-current64/slackware/ap/cups-2.3.0-x86_64-1.txz
which exhibits the hang/freeze behavior,
whereas an earlier install using the identical okular but
slackware-current64/slackware/ap/cups-2.2.10-x86_64-1.txz
never had any problems.

That seems to be a pretty old okular version. okular --version shows
Qt: 4.8.7
KDE Development Platform: 4.14.38
Okular: 0.20.3
And I tried updating okular using the package at
https://slackware.pkgs.org/14.2/ktown-x86_64/
okular-17.08.3-x86_64-1alien.txz.html
And that installed okay, but wouldn't run due to a plethora
of dependencies which I gave up trying to install.

So I'm thinking it's some kind of interoperability problem
whereby the more recent cups is somehow not backwards compatible
with the older okular. But that's just a wild guess.
When I get an opportunity, I'll try re-installing the older
cups, and if that works, then the slackware guys may need to
tweak the distro so that their distributed packages work together.
Post by Rudolf Mueller
That seems too be an explanation for oddities I had with printing
first print pdf in okular ok,
print it again for second copy --> okular hangs
I'm not sure, if this were problematic PDFs or normal, but I think
it appeared to be the case for any of them.
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
John Forkosh
2020-02-08 05:01:53 UTC
Reply
Permalink
Post by Rudolf Mueller
I have this problem too.
Pretty much ignore my preceding followup to you,
and first see Henrik's post and my followup to him,
whereby he seems to have identified both our problems...

first run ps ax | grep cups
and then kill <pid>
the pid of the cupsd daemon process.

Now try running okular against one of the pdfs that hangs it.
I'll bet you that free beer which I owe Henrik that
it's working now. :)
Post by Rudolf Mueller
For me, it seems to be a problem, who has the pdf created
or with which tool. Many make the problem at about +/- 10 pages,
I can open it with a new okular-session starting with the
last page which was ok until it freezes again an so on.
Otherwise i can open pdfs with some hundred pages and have
no problem at all ...
And it makes no difference, if I access the pages by the
preview slider or paging down in the content. The number of
pages seems to be constant for a given pdf which causes the error.
Regards ;)
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
Rich
2020-02-07 01:57:27 UTC
Reply
Permalink
Post by John Forkosh
Yeah, I have three other boxes with the identical slackware
installed, and also can't reproduce the problem on any other box.
Something-or-other must have gotten corrupted/messed-up/whatever,
probably by something I did on this box, but I have no idea what
that might be. And that's what I'm trying to identify (and fix).
You don't know what you did, yet somehow you expect us, with even less
knowledge of you and your system, to magically identify what you did
and tell you how to undo it?
Post by John Forkosh
Post by Jimmy Johnson
Start okular as user from the console and tell us what errors you
get when you get the errors. Also you can try and open pdf using
xpdf it's also installed.
I usually do start okular from a /usr/bin/konsole terminal window.
No errors at all. The okular window just freezes/hangs after a few
pages of scrolling through any pdf (large or small). And the
terminal window shows no messages. Zilch. Nada.
Try it again, and this time, when it freezes, open another terminal
window, find the PID of the okular process, and strace it, and see what
comes out of strace.

strace -p PID

Replace PID with the process id of the frozen okular.
John Forkosh
2020-02-07 04:33:54 UTC
Reply
Permalink
Post by Rich
Post by John Forkosh
Yeah, I have three other boxes with the identical slackware
installed, and also can't reproduce the problem on any other box.
Something-or-other must have gotten corrupted/messed-up/whatever,
probably by something I did on this box, but I have no idea what
that might be. And that's what I'm trying to identify (and fix).
You don't know what you did, yet somehow you expect us, with even less
knowledge of you and your system, to magically identify what you did
and tell you how to undo it?
Like I asked in original post, "...Anybody have any similar experience,
or any suggestion about identifying/fixing the problem?" And I also
mentioned that I'd first googled, hoping to find similar experiences
for which an explanation and solution had already been found.
Post by Rich
Post by John Forkosh
Post by Jimmy Johnson
Start okular as user from the console and tell us what errors you
get when you get the errors. Also you can try and open pdf using
xpdf it's also installed.
I usually do start okular from a /usr/bin/konsole terminal window.
No errors at all. The okular window just freezes/hangs after a few
pages of scrolling through any pdf (large or small). And the
terminal window shows no messages. Zilch. Nada.
Try it again, and this time, when it freezes, open another terminal
window, find the PID of the okular process, and strace it, and see what
comes out of strace.
strace -p PID
Replace PID with the process id of the frozen okular.
I started strace immediately after opening okular, before
it froze, as strace -p PID 2> strace.out in order to see
all the activity leading up to the freeze. I won't bother
you with the first ~10K lines while I was scrolling...

(line 1) strace: Process 4693 attached
(line 2) restart_syscall(<... resuming interrupted poll ...>) = 0

skipping to line 9838 (and wrapping long line)...

stat("/etc/cups/ppd/HL5050.ppd", {st_mode=S_IFREG|0640,
st_size=10023, ...}) = 0
access("/etc/cups/ppd/HL5050.ppd", R_OK) = 0
symlink("/etc/cups/ppd/HL5050.ppd", "/tmp/5e3cde315309c") = 0
openat(AT_FDCWD, "/tmp/5e3cde315309c", O_RDONLY) = 120
fcntl(120, F_GETFD) = 0
fcntl(120, F_SETFD, FD_CLOEXEC) = 0
read(120, "*PPD-Adobe: \"4.3\"\n*%============"..., 4096) = 4096
read(120, "ype BOND/Bond Paper:\n*BrMediaTyp"..., 4096) = 4096
read(120, "Antique: Standard \"(001.005)\" St"..., 4096) = 1831
read(120, "", 4096) = 0
close(120) = 0
unlink("/tmp/5e3cde315309c") = 0
socket(AF_INET6, SOCK_STREAM, IPPROTO_IP) = -1 EAFNOSUPPORT
(Address family not supported by protocol)
socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 120
setsockopt(120, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(120, SOL_SOCKET, SO_REUSEPORT, [1], 4) = 0
setsockopt(120, SOL_TCP, TCP_NODELAY, [1], 4) = 0
fcntl(120, F_SETFD, FD_CLOEXEC) = 0
fcntl(120, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(120, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(120, {sa_family=AF_INET, sin_port=htons(631),
sin_addr=inet_addr("127.0.0.1")}, 16) = -1
EINPROGRESS (Operation now in progress)
fcntl(120, F_SETFL, O_RDWR) = 0
poll([{fd=120, events=POLLIN|POLLOUT}], 1, 250) = 0 (Timeout)
poll([{fd=120, events=POLLIN|POLLOUT}], 1, 250) = 0 (Timeout)
poll([{fd=120, events=POLLIN|POLLOUT}], 1, 250) = 0 (Timeout)
poll([{fd=120, events=POLLIN|POLLOUT}], 1, 250) = 0 (Timeout)
poll([{fd=120, events=POLLIN|POLLOUT}], 1, 250) = 0 (Timeout)
poll([{fd=120, events=POLLIN|POLLOUT}], 1, 250) = 0 (Timeout)
poll([{fd=120, events=POLLIN|POLLOUT}], 1, 250) = 0 (Timeout)
poll([{fd=120, events=POLLIN|POLLOUT}], 1, 250) = 0 (Timeout)
poll([{fd=120, events=POLLIN|POLLOUT}], 1, 250) = 0 (Timeout)
... etc ...
poll([{fd=120, events=POLLIN|POLLOUT}], 1, 250) = 0 (Timeout)
poll([{fd=120, events=POLLIN|POLLOUT}], 1, 250) = 0 (Timeout)
poll([{fd=120, events=POLLIN|POLLOUT}], 1, 250) = ?
ERESTART_RESTARTBLOCK (Interrupted by signal)
--- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=2268, si_uid=1000} ---
+++ killed by SIGTERM +++

So, that "connect(120,..." had been preceded by 119,118,...,25.
And okular had done some "fstat(24,...", 23,etc near the start of the log.
And the 119,118,... connect's were all reading the same ppd file for
my cups default printer. A full sequence for the last successful
one is...

stat("/etc/cups/ppd/HL5050.ppd", {st_mode=S_IFREG|0640,
st_size=10023, ...}) = 0
access("/etc/cups/ppd/HL5050.ppd", R_OK) = 0
symlink("/etc/cups/ppd/HL5050.ppd", "/tmp/5e3cde3152c58") = 0
openat(AT_FDCWD, "/tmp/5e3cde3152c58", O_RDONLY) = 119
fcntl(119, F_GETFD) = 0
fcntl(119, F_SETFD, FD_CLOEXEC) = 0
read(119, "*PPD-Adobe: \"4.3\"\n*%============"..., 4096) = 4096
read(119, "ype BOND/Bond Paper:\n*BrMediaTyp"..., 4096) = 4096
read(119, "Antique: Standard \"(001.005)\" St"..., 4096) = 1831
read(119, "", 4096) = 0
close(119) = 0
unlink("/tmp/5e3cde3152c58") = 0
socket(AF_INET6, SOCK_STREAM, IPPROTO_IP) = -1
EAFNOSUPPORT (Address family not
supported by protocol)
socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 119
setsockopt(119, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(119, SOL_SOCKET, SO_REUSEPORT, [1], 4) = 0
setsockopt(119, SOL_TCP, TCP_NODELAY, [1], 4) = 0
fcntl(119, F_SETFD, FD_CLOEXEC) = 0
fcntl(119, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(119, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(119, {sa_family=AF_INET, sin_port=htons(631),
sin_addr=inet_addr("127.0.0.1")}, 16) = -1
EINPROGRESS (Operation now in progress)
fcntl(119, F_SETFL, O_RDWR) = 0
poll([{fd=119, events=POLLIN|POLLOUT}], 1, 250) = 1
([{fd=119, revents=POLLOUT}])

after which the very next line is the stat(... for "120",

stat("/etc/cups/ppd/HL5050.ppd", {st_mode=S_IFREG|0640,
st_size=10023, ...}) = 0
access("/etc/cups/ppd/HL5050.ppd", R_OK) = 0

etc, etc (i.e., same lines as shown for "120" earlier)
.
So, apparaently, the "poll([{fd=120,..." just kept repeating forever.
No idea why, and no idea why it was reading/re-reading/re-re...
that ppd file. I never asked it to print or print-preview anything.
Also, just in case the ppd file was flaky, I went into cups and
changed the default printer, and then re-ran okular. And that strace
showed it was obediently reading/re-reading a different ppd file.
But the end result was identical.
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
Henrik Carlqvist
2020-02-07 07:37:44 UTC
Reply
Permalink
socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 120 setsockopt(120,
SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 setsockopt(120, SOL_SOCKET,
SO_REUSEPORT, [1], 4) = 0 setsockopt(120, SOL_TCP, TCP_NODELAY, [1], 4)
= 0 fcntl(120, F_SETFD, FD_CLOEXEC) = 0 fcntl(120, F_GETFL)
= 0x2 (flags O_RDWR)
fcntl(120, F_SETFL, O_RDWR|O_NONBLOCK) = 0 connect(120,
{sa_family=AF_INET, sin_port=htons(631),
sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS
(Operation now in progress)
fcntl(120, F_SETFL, O_RDWR) = 0 poll([{fd=120,
events=POLLIN|POLLOUT}], 1, 250) = 0 (Timeout)
poll([{fd=120, events=POLLIN|POLLOUT}], 1, 250) = 0 (Timeout)
poll([{fd=120, events=POLLIN|POLLOUT}], 1, 250) = 0 (Timeout)
This seems to be a problem with your CUPS installation, okular tries to
connect to port 631 on host 127.0.0.1 which is the Internet Printing
Protocol on your localhost.

regards Henrik
John Forkosh
2020-02-08 04:42:59 UTC
Reply
Permalink
Post by Henrik Carlqvist
socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 120 setsockopt(120,
SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 setsockopt(120, SOL_SOCKET,
SO_REUSEPORT, [1], 4) = 0 setsockopt(120, SOL_TCP, TCP_NODELAY, [1], 4)
= 0 fcntl(120, F_SETFD, FD_CLOEXEC) = 0 fcntl(120, F_GETFL)
= 0x2 (flags O_RDWR)
fcntl(120, F_SETFL, O_RDWR|O_NONBLOCK) = 0 connect(120,
{sa_family=AF_INET, sin_port=htons(631),
sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS
(Operation now in progress)
fcntl(120, F_SETFL, O_RDWR) = 0 poll([{fd=120,
events=POLLIN|POLLOUT}], 1, 250) = 0 (Timeout)
poll([{fd=120, events=POLLIN|POLLOUT}], 1, 250) = 0 (Timeout)
poll([{fd=120, events=POLLIN|POLLOUT}], 1, 250) = 0 (Timeout)
This seems to be a problem with your CUPS installation, okular tries to
connect to port 631 on host 127.0.0.1 which is the Internet Printing
Protocol on your localhost.
regards Henrik
Thanks, Henrik. Yeah, I point my browser to localhost:631/
all the time, to manage cups, and had noticed the strace was
doing that. But cups seems okay, as far as I can tell, and
stuff prints fine when printed through acroread, and even
through okular for pdf files that don't hang it.

So I'd guess that the symptom isn't cups, per se, but why
okular is doing all those hundred-plus opens/reads/closes/connects
in the first place.

But I agree with you it's something about the slackware installation
on this box: (a)okular had been working just fine on this box until
one or two weeks ago, and (b)I tested two other boxes with slackware
installed from exactly the same usb stick boot/install medium,
and okular is still (and always had been) working just fine on them.

Now, assuming you're right that "cups is the culprit", is the test
just to reinstall it? Or can I just chmod 644 /etc/rc.d/rc.cups
to turn it off?...

/* +------------------------------------------------------------+
|+----------------------------------------------------------+|
|| OKAY -- NEVER MIND EVERYTHING ABOVE AND READ BELOW ||
|+----------------------------------------------------------+|
+------------------------------------------------------------+ */

...I think you hit the nail/cups on the head.
ps ax|grep cups gave me
1102 ? Ss 0:00 /usr/sbin/cupsd -C /etc/cups/cupsd.conf
-s /etc/cups/cups-files.conf
And so I tried (as root) kill 1102
And "poof", okular now reads/scrolls/etc all the files
that had hung it just a few minutes ago.

Good work, Henrik! And thanks again (and a free beer next time
you're in New York City). So how can I track down whatever
apparently somehow got mis-configured in cups during the past
few weeks, so that I can leave the daemon running? I can't recall
explicitly doing anything that would even remotely affect it,
but I apparently must be wrong about that.
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
Henrik Carlqvist
2020-02-08 06:33:48 UTC
Reply
Permalink
So how can I track down whatever apparently somehow got
mis-configured in cups during the past few weeks, so that I can leave
the daemon running? I can't recall explicitly doing anything that would
even remotely affect it, but I apparently must be wrong about that.
The first thing I would do to trace the latest changes to a machine would
be:

ls -alrt /var/log/packages

But that only shows which packages has gotten newly installed or upgraded.

The second thing to do would be to look for manual configuration changes,
those are usually done in or below the /etc directory:

ls -alrt /etc
ls -alrt /etc/ntp
...

But some files below /etc like /etc/mtab are supposed to get changed by
the system.

It might also be worth looking in the users home directory if some
configuration has changed, the easiest way to check if any user file
affects the problem might be to log in as another user and see if that
user also has the problem.

Finally it might be worth checking that your problem is not caused by any
filled up partition:

df -h

regards Henrik
John Forkosh
2020-02-08 11:21:42 UTC
Reply
Permalink
Post by Henrik Carlqvist
So how can I track down whatever apparently somehow got
mis-configured in cups during the past few weeks, so that
I can leave the daemon running? I can't recall explicitly
doing anything that would even remotely affect it, but
I apparently must be wrong about that.
The first thing I would do to trace the latest changes
ls -alrt /var/log/packages
But that only shows which packages has gotten newly
installed or upgraded.
The second thing to do would be to look for manual configuration
ls -alrt /etc
ls -alrt /etc/ntp
...
But some files below /etc like /etc/mtab are supposed to get
changed by the system.
It might also be worth looking in the users home directory if some
configuration has changed, the easiest way to check if any user file
affects the problem might be to log in as another user and see if that
user also has the problem.
Finally it might be worth checking that your problem is not caused
df -h
regards Henrik
Thanks again, Henrik. But, no, nothing like that shows anything.
I should have mentioned that this box is my personal workstation,
on which I installed slackware myself, and I'm the only (besides
root) user. So, although I did double-check that stuff, I'd have
necessarily known if anything was intentionally done.

But I just did do one thing that actually worked. I ran
/etc/rc.d/rc.cups start
to bring up cupsd. And okular again froze as expected.
But then I went into cups at localhost:631/ and deleted all
the printers. And now okular works, even with cupsd running.

So what does that suggest??? I'd been using a Brother HLL-2395DW,
originally installed using Brother's
linux-brprinter-installer-2.2.1-1
shell script, downloaded from their site. And that was working fine.
Printing fine, and the scanner was immediately recognized by xsane,
and was scanning fine, too. And for months after that, okular was
working fine with that printer installed. And that was the only
installed printer when okular started freezing a week or two ago.
I subsequently installed my very old HL-5050, just to do some
additional okular/cups tests, but okular was already freezing,
so that HL-5050 stuff can't have caused the problem (retro-causation
and time-travel notwithstanding:).

I'll have to try re-installing the HLL-2395DW to see what happens,
but haven't gotten around to that yet. Meanwhile, whatever happens,
it would be good to have some idea/theory about what the heck the
underlying problem is. uninstalling/re-installing the printer, every
time I want to use okular versus print something, is no solution.
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
Henrik Carlqvist
2020-02-09 13:53:01 UTC
Reply
Permalink
I'm the only (besides root) user.
It is rather easy to configure a clean test user account, as root just:

useradd sometest

and answer the questions.
I'd been using a Brother HLL-2395DW, originally installed using
Brother's linux-brprinter-installer-2.2.1-1 shell script, downloaded
from their site. And that was working fine. Printing fine, and the
scanner was immediately recognized by xsane, and was scanning fine,
too. And for months after that, okular was working fine with that
printer installed.
Could it be that you during those months simply didn't look at any of
those pdf files which were able to trig the problem? Maybe those pdf
files have pages which somehow gets too complex for the printer drivers
to handle like too big pages or too much graphics?
I'll have to try re-installing the HLL-2395DW to see what happens, but
haven't gotten around to that yet. Meanwhile, whatever happens, it would
be good to have some idea/theory about what the heck the underlying
problem is. uninstalling/re-installing the printer, every time I want to
use okular versus print something, is no solution.
Whate does the linux-brprinter-installer-2.2.1-1 file contain? Does it
install some filter for cups or daemon that is needed? Do you really need
that file to print? Looking at the specifications for your printer it
seems that it supports PCL6 printing language and the lpr and ipp network
protocols. Maybe you could configure cups to use it as some generic
remote printer instead of using the drivers provided by brother?

Otherwise if you want to track this down you will need to start by
stracing cups and any other daemon involved in printing. Once you find
which program is causing the problem the next step is to recompile that
program with debug options and use a debugger like gdb to really see what
is happening. Once you see what is wrong you fix the source code, verify
that it works and submit a patch upstream. If the brother driver is a
binary driver without source you won't be able to do that, only brother
themselves will be able to fix it.

If trying to fix the problem is too much work you will instead have to
work around it by replacing components causing the problem:

* Use other pdf files
* Use another program to watch pdf files
* Try using another printing system (like LPRng)
* Try using another printer, maybe with another printing language like
PostScript

The above list is sorted in some kind of growing cost when it comes to
time and investments.

regards Henrik
John Forkosh
2020-02-10 10:02:35 UTC
Reply
Permalink
Post by Henrik Carlqvist
I'm the only (besides root) user.
useradd sometest
and answer the questions.
Yes, when I said "But, no, nothing like that shows anything"
in preceding post, that was the answers -- I checked out everything
you suggested with respect to my own account. And I only mentioned
"I'm the only (besides root) user" to point out that I'd know if
anybody had changed anything because I'm the only body using the box.
Post by Henrik Carlqvist
I'd been using a Brother HLL-2395DW, originally installed using
Brother's linux-brprinter-installer-2.2.1-1 shell script, downloaded
from their site. And that was working fine. Printing fine, and the
scanner was immediately recognized by xsane, and was scanning fine,
too. And for months after that, okular was working fine with that
printer installed.
Could it be that you during those months simply didn't look at any of
those pdf files which were able to trig the problem? Maybe those pdf
files have pages which somehow gets too complex for the printer drivers
to handle like too big pages or too much graphics?
Could be -- I'd recently updated my -current64 from everything
downloaded on 3/1/19 to everything downloaded on 9/1/19.
And if I had to guess, I'd guess it's an interoperability problem
with the pretty old okular version...
slackware64-current/slackware/kde/okular-4.14.3-x86_64-3.txz
which is identical on both 3/1/19 and 9/1/19
not working together with the newer 9/1/19 cups...
cups-2.2.10-x86_64-1.txz on 3/1/19
cups-2.3.0-x86_64-1.txz on 9/1/19
I tried updating okular using
https://slackware.pkgs.org/14.2/ktown-x86_64/
okular-17.08.3-x86_64-1alien.txz.html
And that installed okay, but wouldn't run due to a plethora
of dependencies which I gave up trying to install them all.
Post by Henrik Carlqvist
I'll have to try re-installing the HLL-2395DW to see what happens,
but haven't gotten around to that yet.
Well, I've gotten around to it now, and it re-introduces the
okular hang/freeze, just like it was before.
Post by Henrik Carlqvist
Meanwhile, whatever happens, it would
be good to have some idea/theory about what the heck the underlying
problem is. uninstalling/re-installing the printer, every time I want
to use okular versus print something, is no solution.
What does the linux-brprinter-installer-2.2.1-1 file contain? Does it
install some filter for cups or daemon that is needed? Do you really need
that file to print?
That installer is a shell script for linux, common to all Brother
printers. You run it as root, with the printer powered-up and
available, tell the script the printer name, e.g., HLL-2395DW,
and then the script downloads and installs everything needed
automatically. Even "adds" the printer in cups, places ppd files
and other files where they all belong, etc, etc. And then you
can just begin printing, scanning, whatever immediately.
No further setup required. It's quite nice linux support.

You ask "what does the file contain?" It's 143,096 bytes
and 3093 lines, so I'll just say it's a black box.
But it's always "just worked", and not likely causing
a problem as weird as this.
Post by Henrik Carlqvist
Looking at the specifications for your printer it
seems that it supports PCL6 printing language and the lpr and ipp network
protocols. Maybe you could configure cups to use it as some generic
remote printer instead of using the drivers provided by brother?
Otherwise if you want to track this down you will need to start by
stracing cups and any other daemon involved in printing. Once you find
which program is causing the problem the next step is to recompile that
program with debug options and use a debugger like gdb to really see what
is happening. Once you see what is wrong you fix the source code, verify
that it works and submit a patch upstream. If the brother driver is a
binary driver without source you won't be able to do that, only brother
themselves will be able to fix it.
If trying to fix the problem is too much work you will instead have to
* Use other pdf files
* Use another program to watch pdf files
* Try using another printing system (like LPRng)
* Try using another printer, maybe with another printing language like
PostScript
The above list is sorted in some kind of growing cost when it comes to
time and investments.
regards Henrik
Actually, the very simplest "fix"/workaround is to run
/etc/rc.d/rc.cups stop
and to only start it up when I actually need to print something.
That's what I've been doing since I stumbled across that solution,
and it works fine. It'd be nicer to identify the underlying cause,
but I've pretty much given up on that.
Thanks again for all your help.
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
Henrik Carlqvist
2020-02-11 06:47:17 UTC
Reply
Permalink
And if I had to guess, I'd guess it's an interoperability problem with
the pretty old okular version...
slackware64-current/slackware/kde/okular-4.14.3-x86_64-3.txz
which is identical on both 3/1/19 and 9/1/19 not working together with
the newer 9/1/19 cups...
cups-2.2.10-x86_64-1.txz on 3/1/19
cups-2.3.0-x86_64-1.txz on 9/1/19
Maybe it would help to use the Slackware build script to rebuild okular
from source with the new cups installed?

regards Henrik
Mike
2020-02-07 09:09:11 UTC
Reply
Permalink
Post by John Forkosh
I usually do start okular from a /usr/bin/konsole terminal window.
No errors at all. The okular window just freezes/hangs after a
few pages of scrolling through any pdf (large or small). And
the terminal window shows no messages. Zilch. Nada.
Any interesting rumblings in /var/spool/messages or /var/spool/syslog
around the time of the freeze? It may not be okular entirely at
fault, but an interaction between okular and X, KDE, memory
management -- sometimes okular acts up here (blank pages/black
pages) and there's always bleating from video driver about things
in syslog/messages.

Just wondered if you'd looked there for errors beyond okular's
remit?
--
--------------------------------------+------------------------------------
Mike Brown: mjb[-at-]signal11.org.uk | http://www.signal11.org.uk
John Forkosh
2020-02-08 04:52:47 UTC
Reply
Permalink
Post by Mike
Post by John Forkosh
I usually do start okular from a /usr/bin/konsole terminal window.
No errors at all. The okular window just freezes/hangs after a
few pages of scrolling through any pdf (large or small). And
the terminal window shows no messages. Zilch. Nada.
Any interesting rumblings in /var/spool/messages or /var/spool/syslog
around the time of the freeze? It may not be okular entirely at
fault, but an interaction between okular and X, KDE, memory
management -- sometimes okular acts up here (blank pages/black
pages) and there's always bleating from video driver about things
in syslog/messages.
Just wondered if you'd looked there for errors beyond okular's
remit?
Thanks, Mike. Good idea, I'd neglected to look there (/var/log/...).
But nope, nothing seems to be amiss as far as those logs can tell.
But Henrik seems to have found the tree in the forest that's
somehow responsible for the problem. See his post and my followup.
Cups, or some peculiar okular interaction with it, is apparently
causing the problem. But the configuration fix (if that's what's
to blame) is still to be determined (at least it's still a mystery
to me).
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
Rudolf Mueller
2020-02-10 13:57:34 UTC
Reply
Permalink
I'm using latest slackware64-current.
So its okular-4.14.3-x86_64-3 and cups-2.3.1-x86_64-1 and
cups-filters-1.27.0-x86_64-1
with okular part of kde as of 04/2018 and cups-pkps
12/2019 and 01/2020
~
John Forkosh
2020-02-11 02:19:52 UTC
Reply
Permalink
Post by Rudolf Mueller
I'm using latest slackware64-current.
So its okular-4.14.3-x86_64-3 and cups-2.3.1-x86_64-1 and
cups-filters-1.27.0-x86_64-1
with okular part of kde as of 04/2018 and cups-pkps
12/2019 and 01/2020
Thanks for the additional info. Looks like you have the same
okular version that I do, and a later cups. I got an opportunity
to removepkg my current cups and install the earlier version
that had worked. And I figured that either would or wouldn't work.
Surprise, it still hangs -- but after 52 pages rather than 11,
and that behavior is pretty reliably reproducible. Only thing
left to try, as far as I can tell, is to re-install my entire
older distribution on a spare partition, and see what happens.

But since rc.cups stop effectively solves the problem, or at
least its symptoms, that'll be my fix for the forseeable future.
Thanks so much for your help, and for everybody elses, too.
Hope this rc.cups stop workaround is useful for you (and
for anybody else experiencing the same problem).
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
m***@bil.myplace.org
2020-05-06 16:49:41 UTC
Reply
Permalink
Post by John Forkosh
Problem is ... it stopped working. In particular, it opens
a pdf file just fine, but after scrolling through just a few
pages, it completely hangs/freezes, and I have to kill the
process. djvu files work just fine, no problem at all.
Only pdf files hang.
Google gives just a handful of similar problems over the
past several years, and no solutions that seem applicable,
as far as I can tell. I tried rm'ing all the okular stuff
under .kde/, but no luck. And then I tried reinstalling from
my slackware64/kde/okular-4.14.3-x86_64-3.txz file,
first using upgradepkg, and when that didn't change anything
removepkg and installpkg, but that didn't help either.
My slackware is -current64 downloaded 01Sep2019. And okular
had been working fine till just about a week ago. Then "poof".
I'd say that I didn't change anything or do anything, but
that's presumably somehow mistaken. Anybody have any similar
experience, or any suggestion about identifying/fixing the
problem?
It might be worth looking at alien Bob's latest kde5 plasma
packages, for example he released some in january 2020:-
https://alien.slackbook.org/blog/
first-ktown-plasma5-update-for-slackware-in-2020/

He might have done another drop more recently than january, a web search
should tell you. But that article gives you the general idea.

The version of kde shipped with slackware is way old, its much
better to upgrade to his ktown packages to get the latest and
greatest plasma 5 code.

He also makes a standalone slackware64-live iso that you can download
and run which contains the latest kde5 plasma stuff. You could grab
the slackware live image and see if the okular in that version works for you.
It runs straight from a dvd or usb drive, you don't have to install it
first.

My guess is that if you download his ktown stuff you will find its much,
much better than the kde shipped with slackware.
David Chmelik
2020-05-21 07:42:31 UTC
Reply
Permalink
Problem is ... it stopped working. In particular, it opens a pdf file
just fine, but after scrolling through just a few pages, it completely
hangs/freezes, and I have to kill the process. djvu files work just
fine, no problem at all.
Only pdf files hang.
Google gives just a handful of similar problems over the past several
years, and no solutions that seem applicable,
as far as I can tell. I tried rm'ing all the okular stuff under .kde/,
but no luck. And then I tried reinstalling from my
slackware64/kde/okular-4.14.3-x86_64-3.txz file,
first using upgradepkg, and when that didn't change anything removepkg
and installpkg, but that didn't help either.
My slackware is -current64 downloaded 01Sep2019. And okular had been
working fine till just about a week ago. Then "poof".
I'd say that I didn't change anything or do anything, but that's
presumably somehow mistaken. Anybody have any similar experience, or any
suggestion about identifying/fixing the problem?
I got used to liking okular's interface more than I used to like the
original Adobe Reader style, but really, okular is slow for anything but
small (or some small-to-medium) PDFs. For large, or at least huge/
gigantic PDFs, I would never consider okular anymore. People described
for those it's best to use xpdf or try building mupdf from SlackBuilds.org
(SBo, sbopkg.org.)

Loading...