Bug 180521 - okular freezes system upon close after updating latex-compiled pdf while open
Summary: okular freezes system upon close after updating latex-compiled pdf while open
Status: RESOLVED UPSTREAM
Alias: None
Product: okular
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR crash
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
: 184688 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-01-13 04:17 UTC by mattm3a
Modified: 2009-03-02 10:41 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Latex source and eps diagram to cause crash (100.00 KB, application/x-tar)
2009-01-28 07:02 UTC, mattm3a
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mattm3a 2009-01-13 04:17:21 UTC
Version:            (using KDE 4.1.3)
OS:                Linux
Installed from:    SuSE RPMs

This is with the stock suse 11.1 kde 4.1.3 distribution. 

List of steps:
1) open pdf file in okular
2) open latex source file in text editor
3) recompile latex source to pdf
4) wait for okular to update to reflect changes
Steps 2-4 are repeated multiple times throughout a day. At the end of the day:
5) close okular. Watch system lockup completely. 

The crash results in a completely unusable system that must be power cycled. Keyboard and mouse are nonresponsive. 

There is no console output at the time of the crash when running okular from the command line. The same crash with no information occurs when running under gdb and valgrind. 

I can recompile the source file and update the open pdf file at least once, then close okular without crashing the system. I don't know how many updates it takes to create the problem. I have seen the problem occur once while okular was refreshing, but it occurs almost always when closing after having updated many times. 

The latex file is text, equations, and includes eps figures.
Comment 1 Manuel Stahl 2009-01-14 10:24:42 UTC
I experience a similar problem when I try to close okular after refreshing a PDF several times. It doesn't lockup the system but okular cannot be killed with 'killall -SIGKILL okular' and the system is not able to go into suspend mode as the okular process cannot be freezed.
Comment 2 Albert Astals Cid 2009-01-14 21:07:36 UTC
First comment is bug #178147 may or may not be related to this one.
Comment 3 mattm3a 2009-01-28 07:02:56 UTC
Created attachment 30668 [details]
Latex source and eps diagram to cause crash

This bug persists in KDE 4.2

I can reliably produce a system crash by doing the following:
1) Run make to create pdf
2) open pdf in okular
3) touch crash.tex
4) make
5) repeat steps 3 and 4 approximately 10 times
6) close okular
Comment 4 Carlo 2009-02-08 10:48:09 UTC
I can produce this problem also with KPDF shipped with KDE 3.5.10 (however using KDE 4.1.3 and KDE 4.2).
Comment 5 Pino Toscano 2009-02-18 13:09:30 UTC
*** Bug 184688 has been marked as a duplicate of this bug. ***
Comment 6 Daniel Mader 2009-02-19 12:16:58 UTC
I can reproduce 100%. Since it *crashes* the whole system, it's about time to at least confirm it by some KDE-dev, I'd say?!
Comment 7 Pino Toscano 2009-02-19 12:29:10 UTC
(In reply to comment #6)
> I can reproduce 100%. Since it *crashes* the whole system, it's about time to
> at least confirm it by some KDE-dev, I'd say?!

If nobody of us was able to reproduce the problem so far, what should we fix?

And since you are able to reproduce 100%, what about digging in your system logs (like dmesg, /var/log/messages/, /var/log/Xorg.0.log*, etc) and find out more information about it?
Comment 8 Christophe Marin 2009-02-19 12:52:15 UTC
You may also install the kerneloops package and try to reproduce this system crash.

You should find reports in /tmp after restarting.
Comment 9 Christophe Marin 2009-02-19 12:53:27 UTC
Also, please specify which distro you actually use.
Comment 10 Daniel Mader 2009-02-19 13:04:22 UTC
I am using opensuse 11.1 with KDE4 from Factory. Okular build is kde4-okular-4.2.0-71.12.

It's the same on x86_64 on a totally different machine, and it makes no difference if the PDF is stored locally or remotely on a Samba share.

In case you really cannot reproduce (which I seriously doubt -- you just haven't tried), here's my version which works perfectly well: create a PDF document with kile or any other editor of you choice along with pdflatex, change it and re-compile it several times while it is opened in okular. Try to close okular then. Watch what happens.

Unfortunately, I don't have the knowledge to provide logs or anything useful
from a totally frozen system. I will try the kerneloops package.

<rant>I had to remove all KDE4 installations in the lab where I am responsible for the computers. People are running Gnome now, because even with 4.2 the desktop experience is a joke when I take everything into account. Gnome offers everything and it works, while it takes us ages to get serious bugs fixed. Need examples? Take this one, take the ridiculous printing situation (waiting for Qt4.5), take the longtime Samba share bug (finally fixed now), take the ridiculously lousy multi screen situation (partially fixed, issues remain, no tool to set it up). Take many more. I am sick of trying to convince people to wait because eventually the situation will improve.</rant>

It would really be nice, though, from a user's perspective, to get the feeling
people are finally trying to squash bugs like this in KDE.
Comment 11 Pino Toscano 2009-02-19 13:16:43 UTC
(In reply to comment #10)
> In case you really cannot reproduce (which I seriously doubt -- you just
> haven't tried)

What about stopping making fun of us?
Do you think we are stupid or willing to blatantly ignore such kind of bugs?
The fact that a bug is 100% reproducible -for you- does not make it 100% reproducible to -anyone-, and it would be nice to you acknowledge that, instead of speculating we don't care about bugs.

> It would really be nice, though, from a user's perspective, to get the feeling
> people are finally trying to squash bugs like this in KDE.

We provide a number of bug fixes in each patch release, so this statement is kinda useless.
Comment 12 Daniel Mader 2009-02-19 14:24:59 UTC
openSUSE kernel team thinks it's related to a bug in the kernel:
https://bugzilla.novell.com/show_bug.cgi?id=463372

Seems there is a fix on the way, and the bug is not in Okular.
Comment 13 Pino Toscano 2009-02-19 18:11:13 UTC
Inotify bug? Uh, that would explain.

In the meanwhile, anyone affected by the problem can do the following temporary workaround:
a) execute 'kdebugdialog', find and activate the debug area 7001 (KDirWatch)
b) in a terminal, run 'okular somedocument'; you should see in the output a line similar to:
   okular(22280)/kio (KDirWatch) KDirWatchPrivate::KDirWatchPrivate: Available methods:  ("Stat", "INotify")
c) close any open okular you have, and in a terminal do:
   kwriteconfig --file okularrc --group DirWatch --key PreferredMethod XXX
   where XXX should be replaced with
   - "Fam" if you have "FAM" among the available methods above
   - "Stat" otherwise

this will provide you a slightly less efficient way for file monitoring, but at least should not use what looks like to be a buggy inotify on your system.

If you still have problems after setting this, please tell.
Comment 14 Pino Toscano 2009-02-19 18:25:26 UTC
(forgot to add in previous comment)

The other workaround is just to disable the "Reload document on file change" in the configuration. Of course you have no automatic reload :) but you can reload manually via File -> Reload.

To remove the manual setting done via kwriteconfig, open your ~/.kde/share/config/okularrc (or ~/.kde4, depending on your distro), find and remove the lines:
  [DirWatch]
  PreferredMethod=XXX
Comment 15 Maciej Pilichowski 2009-02-19 20:54:06 UTC
Grissiom in https://bugs.kde.org/show_bug.cgi?id=178147 described perfectly "working" steps:

1, In a terminal, use okular to open a pdf file, say temp.pdf
2, run this script in other terminal: 
=============================
#!/bin/bash
i=1
while [ $i -lt 200 ]; do
        mv temp.pdf temp
        sleep 1
        mv temp temp.pdf
        i=$[$i + 1]
done
============================
3, then close the okular window, 

System freeze (I changed 20 to 200 to be sure the system will freeze).

KDE 4.2, x86-64, happens always.
Comment 16 Christophe Marin 2009-03-01 16:50:37 UTC
@All: Opensuse has published a new kernel for 11.1 which adresses the inotify issue.

Please upgrade and test.
Comment 17 Daniel Mader 2009-03-01 18:29:09 UTC
I can no longer reproduce with 2.6.27.19-3.2-default on openSUSE 11.1 (both i386 and x86_64).
Comment 18 Maciej Pilichowski 2009-03-01 20:15:33 UTC
After kernel upgrade, no crash anymore!
Comment 19 mattm3a 2009-03-02 04:05:03 UTC
My hard lock issue is fixed by the kernel update.
Comment 20 Pino Toscano 2009-03-02 10:41:38 UTC
Ok, this looks enough to conclude it was a bad INotify regression (just on openSUSE?).