https://bugs.kde.org/show_bug.cgi?id=403643
--- Comment #19 from Tobias Deiminger <haxti...@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 watching all bug changes.
