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.
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.
First comment is bug #178147 may or may not be related to this one.
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
I can produce this problem also with KPDF shipped with KDE 3.5.10 (however using KDE 4.1.3 and KDE 4.2).
*** Bug 184688 has been marked as a duplicate of this bug. ***
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?!
(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?
You may also install the kerneloops package and try to reproduce this system crash. You should find reports in /tmp after restarting.
Also, please specify which distro you actually use.
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.
(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.
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.
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.
(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
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.
@All: Opensuse has published a new kernel for 11.1 which adresses the inotify issue. Please upgrade and test.
I can no longer reproduce with 2.6.27.19-3.2-default on openSUSE 11.1 (both i386 and x86_64).
After kernel upgrade, no crash anymore!
My hard lock issue is fixed by the kernel update.
Ok, this looks enough to conclude it was a bad INotify regression (just on openSUSE?).