[okular] [Bug 403643] Okular stops rendering PDF and uses up 100% cpu (possible regression)
https://bugs.kde.org/show_bug.cgi?id=403643 --- Comment #24 from Tobias Deiminger --- Git commit 593803b0a1d98eba64aac38316aa521130b4ae78 by Tobias Deiminger. Committed on 30/01/2020 at 08:15. Pushed by aacid into branch 'release/19.12'. Fix render stop and high load due to timing issue Text generation is connected to pixmap generation thread started signal. However the signal may have been emitted faster than the connect could took place, and because started is fired only once, the connected lambda never got executed. generatePixmap tried to sync up with that never happening text generation anyway by means of scheduling itself. This lead to a infinite loop via a no more sleeping QEventLoop. Fixed by moving the connect in front of starting the thread. Related: bug 396137, bug 396087 M +2-2core/generator.cpp https://invent.kde.org/kde/okular/commit/593803b0a1d98eba64aac38316aa521130b4ae78 -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 403643] Okular stops rendering PDF and uses up 100% cpu (possible regression)
https://bugs.kde.org/show_bug.cgi?id=403643 --- Comment #23 from Tobias Deiminger --- Merge request at https://invent.kde.org/kde/okular/merge_requests/98 describes and fixes the issue I was able to reproduce locally. Hopefully it's the same as root cause as our bug reporters observed. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 403643] Okular stops rendering PDF and uses up 100% cpu (possible regression)
https://bugs.kde.org/show_bug.cgi?id=403643 --- Comment #22 from Tobias Deiminger --- I can now reproduce the issue (CPU 30%, pages no more rendered, but okular symbol shown) in Ubuntu 19.10. But: For me it happens only if strace is attached to okular while scrolling through a PDF (the one from bug 39613). The issue then remains after detaching strace, it will never recover, and can be observed by attaching gdb. I see that QEventLoop is no more going to sleep, because the underlying poll() system call is always called with a timeout of 0, and that generatePixmap is called at high frequency while TextPageGenerationThread::isFinished == 1. Can't go on for today, but seems like a good position to continue debugging upcoming days. Albert, could you try if the "strace trick" helps to reproduce the issue at your side? -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 403643] Okular stops rendering PDF and uses up 100% cpu (possible regression)
https://bugs.kde.org/show_bug.cgi?id=403643 --- Comment #21 from Tobias Deiminger --- (In reply to Oliver Sander from comment #20) > Tobias, you can suggest that to me. Ok, suggested herewith :) -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 403643] Okular stops rendering PDF and uses up 100% cpu (possible regression)
https://bugs.kde.org/show_bug.cgi?id=403643 --- Comment #20 from Oliver Sander --- > Other ways of debugging could be to collect more data by means of a remotely > executed gdb script or even a remote gdb session. But both have severe > privacy/security implications, so I'm not sure if we could even suggest this > to bug reporters. Tobias, you can suggest that to me. I cannot reproduce the issue reliably, but it does happen regularly. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 403643] Okular stops rendering PDF and uses up 100% cpu (possible regression)
https://bugs.kde.org/show_bug.cgi?id=403643 --- Comment #19 from Tobias Deiminger --- (In reply to Albert Astals Cid from comment #18) > The timer is not the problem, that timer gets triggered quite easily and > doesn't infinite loop. > > The problem is that sometimes it seems to infinite loop, so yeah, no idea :D Just thought about scenarios how such an inifte loop could occur. All can be ruled out by attached backtraces: - isFinished never signaled - can be ruled out: If TextPageGenerationThread ran forever, TextPageGenerationThread::run would be on stack, but it's not. If the thread exited non-gracefully (i.e. abort()/SIGABRT), the whole program would have crashed, but it did not. - textpageGenerationFinished() never called - can be ruled out: It's connected to finished(), then same reasons as above apply. - textpageGenerationFinished() called, but QMutexLocker blocking forever - can be ruled out: textpageGenerationFinished is called in main thread via QueuedConnection, so the lock() would be visible on Thread 1 stack, and more, the mutex would also block the single shot timer, which is obviously not the case. After that I see no possibility for an infinite loop. How about generatePixmap simply being called very frequently in regular ways, then hitting the singleShot sometimes (but leaving it again), misleading us? I'll try to reproduce in kubuntu 19.10. Other ways of debugging could be to collect more data by means of a remotely executed gdb script or even a remote gdb session. But both have severe privacy/security implications, so I'm not sure if we could even suggest this to bug reporters. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 403643] Okular stops rendering PDF and uses up 100% cpu (possible regression)
https://bugs.kde.org/show_bug.cgi?id=403643 --- Comment #18 from Albert Astals Cid --- (In reply to Tobias Deiminger from comment #17) > (In reply to Postix from comment #10) > > There are also a few lines with > > > generatePixmap > > Qt has a shortcut for QTimer::singleShot(msec = 0, ...), where they call > QMetaObject::invokeMethodImpl to trigger your lambda immediately via a > QueuedConnection plus one iteration through the event loop. > > So a callstack like yours > #n+1 QMetaObject::invokeMethodImpl > #n Okular::Generator::generatePixmap > ... > #n-m QCoreApplicationPrivate::sendPostedEvents > could indeed stem from a "text generation already finished but > mTextPageReady still false" endless loop, assuming the compiler has inlined > some calls for optimization. Note the "could", I see no definite proof yet. > > I generally agree with Albert that this issue is particularly hard to debug > without being able to reproduce it locally. The timer is not the problem, that timer gets triggered quite easily and doesn't infinite loop. The problem is that sometimes it seems to infinite loop, so yeah, no idea :D -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 403643] Okular stops rendering PDF and uses up 100% cpu (possible regression)
https://bugs.kde.org/show_bug.cgi?id=403643 Tobias Deiminger changed: What|Removed |Added CC||haxti...@posteo.de --- Comment #17 from Tobias Deiminger --- (In reply to Postix from comment #10) > There are also a few lines with > > generatePixmap Qt has a shortcut for QTimer::singleShot(msec = 0, ...), where they call QMetaObject::invokeMethodImpl to trigger your lambda immediately via a QueuedConnection plus one iteration through the event loop. So a callstack like yours #n+1 QMetaObject::invokeMethodImpl #n Okular::Generator::generatePixmap ... #n-m QCoreApplicationPrivate::sendPostedEvents could indeed stem from a "text generation already finished but mTextPageReady still false" endless loop, assuming the compiler has inlined some calls for optimization. Note the "could", I see no definite proof yet. I generally agree with Albert that this issue is particularly hard to debug without being able to reproduce it locally. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 403643] Okular stops rendering PDF and uses up 100% cpu (possible regression)
https://bugs.kde.org/show_bug.cgi?id=403643 --- Comment #16 from Albert Astals Cid --- (In reply to Albert Astals Cid from comment #15) > (In reply to Postix from comment #14) > > (In reply to Albert Astals Cid from comment #13) > > > > > > *** This bug has been marked as a duplicate of bug 396137 *** > > > > Albert, have my efforts at least helped you a little bit besides probably > > identifying this bug as a duplicate? I just hope I did not invest so much > > time for nothing. :-/ > > Sadly not really, have not been able to reproduce it myself nor I have find > any good clue on the backtraces :/ One thing, since you seem to be able to reproduce it relatively easily, could you try okular from flathub and try reproducing it using that okular instead of your distribution one? https://flathub.org/apps/details/org.kde.okular -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 403643] Okular stops rendering PDF and uses up 100% cpu (possible regression)
https://bugs.kde.org/show_bug.cgi?id=403643 --- Comment #15 from Albert Astals Cid --- (In reply to Postix from comment #14) > (In reply to Albert Astals Cid from comment #13) > > > > *** This bug has been marked as a duplicate of bug 396137 *** > > Albert, have my efforts at least helped you a little bit besides probably > identifying this bug as a duplicate? I just hope I did not invest so much > time for nothing. :-/ Sadly not really, have not been able to reproduce it myself nor I have find any good clue on the backtraces :/ -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 403643] Okular stops rendering PDF and uses up 100% cpu (possible regression)
https://bugs.kde.org/show_bug.cgi?id=403643 --- Comment #14 from Postix --- (In reply to Albert Astals Cid from comment #13) > > *** This bug has been marked as a duplicate of bug 396137 *** Albert, have my efforts at least helped you a little bit besides probably identifying this bug as a duplicate? I just hope I did not invest so much time for nothing. :-/ -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 403643] Okular stops rendering PDF and uses up 100% cpu (possible regression)
https://bugs.kde.org/show_bug.cgi?id=403643 Albert Astals Cid changed: What|Removed |Added Resolution|--- |DUPLICATE Status|CONFIRMED |RESOLVED --- Comment #13 from Albert Astals Cid --- *** This bug has been marked as a duplicate of bug 396137 *** -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 403643] Okular stops rendering PDF and uses up 100% cpu (possible regression)
https://bugs.kde.org/show_bug.cgi?id=403643 Postix changed: What|Removed |Added Attachment #125432|0 |1 is obsolete|| --- Comment #12 from Postix --- Created attachment 125435 --> https://bugs.kde.org/attachment.cgi?id=125435&action=edit gdb backtrace #3 Update. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 403643] Okular stops rendering PDF and uses up 100% cpu (possible regression)
https://bugs.kde.org/show_bug.cgi?id=403643 Postix changed: What|Removed |Added Attachment #125431|0 |1 is obsolete|| --- Comment #11 from Postix --- Created attachment 125432 --> https://bugs.kde.org/attachment.cgi?id=125432&action=edit GDB Backtrace Some more ctrl+c/thread apply bt full/continue sequences. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 403643] Okular stops rendering PDF and uses up 100% cpu (possible regression)
https://bugs.kde.org/show_bug.cgi?id=403643 Postix changed: What|Removed |Added Attachment #125427|0 |1 is obsolete|| --- Comment #10 from Postix --- Created attachment 125431 --> https://bugs.kde.org/attachment.cgi?id=125431&action=edit gdb backtrace #2 I tried it again just as you described it here: https://bugs.kde.org/show_bug.cgi?id=396137#c1 There are also a few lines with > generatePixmap like in the other report: https://bugs.kde.org/show_bug.cgi?id=396137#c2 Hopefully you are now more happy or do you need more bt/ctrl+c/continue sequences? P.S. I also send you a mail. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 403643] Okular stops rendering PDF and uses up 100% cpu (possible regression)
https://bugs.kde.org/show_bug.cgi?id=403643 --- Comment #9 from Postix --- (In reply to Albert Astals Cid from comment #8) > The backtrace is not very useful really, also it seems like you were trying > to quit okular, did you do that? If so, don't do that. I don't quit Okular but at one step I need to hold the program (ctrl + c) in gdb to generate the debug trace? I kindly asked you how I do it correctly. What I did exactly I mentioned above. > Sure send me the file, but you didn't answer the important question of "it's > relatively easy to reproduce" There was no "question" and if there was one, I answered it implicitly: Yes it's easy to reproduce on my side. ;) -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 403643] Okular stops rendering PDF and uses up 100% cpu (possible regression)
https://bugs.kde.org/show_bug.cgi?id=403643 --- Comment #8 from Albert Astals Cid --- The backtrace is not very useful really, also it seems like you were trying to quit okular, did you do that? If so, don't do that. Sure send me the file, but you didn't answer the important question of "it's relatively easy to reproduce" -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 403643] Okular stops rendering PDF and uses up 100% cpu (possible regression)
https://bugs.kde.org/show_bug.cgi?id=403643 --- Comment #7 from Postix --- Created attachment 125427 --> https://bugs.kde.org/attachment.cgi?id=125427&action=edit gdb stacktrace (In reply to Albert Astals Cid from comment #6) > "thread apply all bt" in gdb > Also ideally do that before closing I tried it again, this time with a debug build of Okular and the qt-debug packages on Manjaro Unstable in a virtual machine. Also glibc-debug was installed, but it still seems to lack the debug symbols. What did I do? 1) Started Okular with gdb gdb okular gdb run 2) Loaded a troublesome PDF and started scrolling until the CPU went high and no more - not yet rendered - pages were loaded 3) Interrupted the process in the terminal by ctrl+c 4) Generated the backtrace via thread apply all bt full which is now attached and hopefully more useful to you now. If not, please tell what I should do instead or additionally of steps 1) to 4). :) > Also if you have a file in which it's relatively easy to reproduce, attach it With 17 MB it's too big to attach it here. Maybe I can send it to you via mail? -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 403643] Okular stops rendering PDF and uses up 100% cpu (possible regression)
https://bugs.kde.org/show_bug.cgi?id=403643 Albert Astals Cid changed: What|Removed |Added CC||aa...@kde.org --- Comment #6 from Albert Astals Cid --- (In reply to Postix from comment #4) > (In reply to Oliver Sander from comment #3) > > Is this the same as https://bugs.kde.org/show_bug.cgi?id=396137 ? > > It could be, however I don't need to "scroll fast". > > Here's a backtrace when I just happened again. I tried to exit Okular, the > window closed, but the process kept running in the background for a while. > I will try to reproduce it at another time with debug symbols attached. :) > > ``` > [postix ~]# gdb attach `pidof okular` > GNU gdb (GDB) 8.3.1 > > (...) > > Attaching to process 4039 > [New LWP 4041] > [New LWP 4042] > [New LWP 4046] > [New LWP 4047] > [New LWP 4048] > [New LWP 4049] > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/usr/lib/libthread_db.so.1". > 0x7f429aece480 in g_mutex_lock () from /usr/lib/libglib-2.0.so.0 > /usr/lib/../share/gcc-9.2.0/python/libstdcxx/v6/xmethods.py:731: > SyntaxWarning: list indices must be integers or slices, not str; perhaps you > missed a comma? > refcounts = ['_M_refcount']['_M_pi'] > (gdb) bt > #0 0x7f429aece480 in g_mutex_lock () at /usr/lib/libglib-2.0.so.0 > #1 0x7f429af1da0c in g_main_context_prepare () at > /usr/lib/libglib-2.0.so.0 > #2 0x7f429af1e046 in () at /usr/lib/libglib-2.0.so.0 > #3 0x7f429af1e1f1 in g_main_context_iteration () at > /usr/lib/libglib-2.0.so.0 > #4 0x7f429ca78d40 in > QEventDispatcherGlib::processEvents(QFlags) > () at /usr/lib/libQt5Core.so.5 > #5 0x7f429ca1f41c in > QEventLoop::exec(QFlags) () at > /usr/lib/libQt5Core.so.5 > #6 0x7f42947bab7a in () at /usr/lib/libOkular5Core.so.9 > #7 0x7f42947bbe43 in Okular::Document::closeDocument() () at > /usr/lib/libOkular5Core.so.9 > #8 0x7f4294959513 in Okular::Part::closeUrl(bool) () at > /usr/lib/qt/plugins/okularpart.so > #9 0x562c14bdd7b6 in () > #10 0x562c14bdd8c9 in () > #11 0x7f429ca4df50 in QObject::event(QEvent*) () at > /usr/lib/libQt5Core.so.5 > #12 0x7f429d59678b in QWidget::event(QEvent*) () at > /usr/lib/libQt5Widgets.so.5 > #13 0x7f429d6b0865 in QMainWindow::event(QEvent*) () at > /usr/lib/libQt5Widgets.so.5 > #14 0x7f429dec045c in KMainWindow::event(QEvent*) () at > /usr/lib/libKF5XmlGui.so.5 > #15 0x7f429df0b988 in KXmlGuiWindow::event(QEvent*) () at > /usr/lib/libKF5XmlGui.so.5 > #16 0x7f429d552472 in QApplicationPrivate::notify_helper(QObject*, > QEvent*) () at /usr/lib/libQt5Widgets.so.5 > #17 0x7f429d55bc89 in QApplication::notify(QObject*, QEvent*) () at > /usr/lib/libQt5Widgets.so.5 > #18 0x7f429ca208b2 in QCoreApplication::notifyInternal2(QObject*, > QEvent*) () at /usr/lib/libQt5Core.so.5 > #19 0x7f429ca23116 in > QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () at > /usr/lib/libQt5Core.so.5 > #20 0x7f429ca796f4 in () at /usr/lib/libQt5Core.so.5 > #21 0x7f429af1c39e in g_main_context_dispatch () at > /usr/lib/libglib-2.0.so.0 > #22 0x7f429af1e1b1 in () at /usr/lib/libglib-2.0.so.0 > #23 0x7f429af1e1f1 in g_main_context_iteration () at > /usr/lib/libglib-2.0.so.0 > #24 0x7f429ca78d40 in > QEventDispatcherGlib::processEvents(QFlags) > () at /usr/lib/libQt5Core.so.5 > #25 0x7f429ca1f41c in > QEventLoop::exec(QFlags) () at > /usr/lib/libQt5Core.so.5 > #26 0x7f429ca27426 in QCoreApplication::exec() () at > /usr/lib/libQt5Core.so.5 > #27 0x562c14bd379a in () > #28 0x7f429c3f0153 in __libc_start_main () at /usr/lib/libc.so.6 > #29 0x562c14bd47ce in () > ``` This backtrace is not useful, next time you need to trace all threads not just the main one "thread apply all bt" in gdb Also ideally do that before closing Also if you have a file in which it's relatively easy to reproduce, attach it -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 403643] Okular stops rendering PDF and uses up 100% cpu (possible regression)
https://bugs.kde.org/show_bug.cgi?id=403643 --- Comment #5 from Postix --- Additional remark: The CPU goes up to 100% for a single core. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 403643] Okular stops rendering PDF and uses up 100% cpu (possible regression)
https://bugs.kde.org/show_bug.cgi?id=403643 --- Comment #4 from Postix --- (In reply to Oliver Sander from comment #3) > Is this the same as https://bugs.kde.org/show_bug.cgi?id=396137 ? It could be, however I don't need to "scroll fast". Here's a backtrace when I just happened again. I tried to exit Okular, the window closed, but the process kept running in the background for a while. I will try to reproduce it at another time with debug symbols attached. :) ``` [postix ~]# gdb attach `pidof okular` GNU gdb (GDB) 8.3.1 (...) Attaching to process 4039 [New LWP 4041] [New LWP 4042] [New LWP 4046] [New LWP 4047] [New LWP 4048] [New LWP 4049] [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". 0x7f429aece480 in g_mutex_lock () from /usr/lib/libglib-2.0.so.0 /usr/lib/../share/gcc-9.2.0/python/libstdcxx/v6/xmethods.py:731: SyntaxWarning: list indices must be integers or slices, not str; perhaps you missed a comma? refcounts = ['_M_refcount']['_M_pi'] (gdb) bt #0 0x7f429aece480 in g_mutex_lock () at /usr/lib/libglib-2.0.so.0 #1 0x7f429af1da0c in g_main_context_prepare () at /usr/lib/libglib-2.0.so.0 #2 0x7f429af1e046 in () at /usr/lib/libglib-2.0.so.0 #3 0x7f429af1e1f1 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0 #4 0x7f429ca78d40 in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib/libQt5Core.so.5 #5 0x7f429ca1f41c in QEventLoop::exec(QFlags) () at /usr/lib/libQt5Core.so.5 #6 0x7f42947bab7a in () at /usr/lib/libOkular5Core.so.9 #7 0x7f42947bbe43 in Okular::Document::closeDocument() () at /usr/lib/libOkular5Core.so.9 #8 0x7f4294959513 in Okular::Part::closeUrl(bool) () at /usr/lib/qt/plugins/okularpart.so #9 0x562c14bdd7b6 in () #10 0x562c14bdd8c9 in () #11 0x7f429ca4df50 in QObject::event(QEvent*) () at /usr/lib/libQt5Core.so.5 #12 0x7f429d59678b in QWidget::event(QEvent*) () at /usr/lib/libQt5Widgets.so.5 #13 0x7f429d6b0865 in QMainWindow::event(QEvent*) () at /usr/lib/libQt5Widgets.so.5 #14 0x7f429dec045c in KMainWindow::event(QEvent*) () at /usr/lib/libKF5XmlGui.so.5 #15 0x7f429df0b988 in KXmlGuiWindow::event(QEvent*) () at /usr/lib/libKF5XmlGui.so.5 #16 0x7f429d552472 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/libQt5Widgets.so.5 #17 0x7f429d55bc89 in QApplication::notify(QObject*, QEvent*) () at /usr/lib/libQt5Widgets.so.5 #18 0x7f429ca208b2 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib/libQt5Core.so.5 #19 0x7f429ca23116 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () at /usr/lib/libQt5Core.so.5 #20 0x7f429ca796f4 in () at /usr/lib/libQt5Core.so.5 #21 0x7f429af1c39e in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0 #22 0x7f429af1e1b1 in () at /usr/lib/libglib-2.0.so.0 #23 0x7f429af1e1f1 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0 #24 0x7f429ca78d40 in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib/libQt5Core.so.5 #25 0x7f429ca1f41c in QEventLoop::exec(QFlags) () at /usr/lib/libQt5Core.so.5 #26 0x7f429ca27426 in QCoreApplication::exec() () at /usr/lib/libQt5Core.so.5 #27 0x562c14bd379a in () #28 0x7f429c3f0153 in __libc_start_main () at /usr/lib/libc.so.6 #29 0x562c14bd47ce in () ``` -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 403643] Okular stops rendering PDF and uses up 100% cpu (possible regression)
https://bugs.kde.org/show_bug.cgi?id=403643 Oliver Sander changed: What|Removed |Added CC||oliver.san...@tu-dresden.de --- Comment #3 from Oliver Sander --- Is this the same as https://bugs.kde.org/show_bug.cgi?id=396137 ? -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 403643] Okular stops rendering PDF and uses up 100% cpu (possible regression)
https://bugs.kde.org/show_bug.cgi?id=403643 Postix changed: What|Removed |Added Version|19.12.1 |1.9.1 -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 403643] Okular stops rendering PDF and uses up 100% cpu (possible regression)
https://bugs.kde.org/show_bug.cgi?id=403643 Postix changed: What|Removed |Added Platform|Ubuntu Packages |unspecified Ever confirmed|0 |1 Version|1.4.3 |19.12.1 Status|REPORTED|CONFIRMED CC||pos...@posteo.eu --- Comment #2 from Postix --- I can confirm this issue. I have an PDF with a lots of scanned pages from a text book. After scrolling and reading a while Okular stops rendering new pages and a few appear extremely blurry. At the same time the CPU goes to 100% and I can no longer close the tab of the document, which has problems. However, I can close the Okular app itself, however it does not terminate actually, but the process keeps running in the background with 100% CPU. # System settings Operating System: Manjaro Linux KDE Plasma Version: 5.17.5 KDE Frameworks Version: 5.67.0 Qt Version: 5.14.0 Kernel Version: 5.4.13-3-MANJARO OS Type: 64-bit Processors: 4 × Intel® Core™ i7-7500U CPU @ 2.70GHz Memory: 15,4 GiB # Additional information RAM settings are were either set to 2nd or highest setting. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 403643] Okular stops rendering PDF and uses up 100% cpu (possible regression)
https://bugs.kde.org/show_bug.cgi?id=403643 Michael D changed: What|Removed |Added CC||nortex...@gmail.com --- Comment #1 from Michael D --- I had the same issue today and wondered why my battery life was plummeting. I'm on Manjaro testing, okular 1.6.2. -- You are receiving this mail because: You are watching all bug changes.
