[okular] [Bug 403643] Okular stops rendering PDF and uses up 100% cpu (possible regression)

Tobias Deiminger bugzilla_noreply at kde.org
Tue Jan 28 07:56:47 GMT 2020


https://bugs.kde.org/show_bug.cgi?id=403643

--- Comment #19 from Tobias Deiminger <haxtibal at posteo.de> ---
(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 the assignee for the bug.


More information about the Okular-devel mailing list