On Mon, 2026-07-13 at 09:21 +0200, Stefano Crocco wrote: > On lunedì 13 luglio 2026 08:49:46 Ora legale dell’Europa centrale you > wrote: > > On Mon, 2026-07-13 at 08:41 +0200, Stefano Crocco wrote: > > > Hello to everyone, > > > for the last few weeks, I've randomly encountered what I assume > > > is a > > > bug in > > > Konqueror: I'd like to fix it, because it's rather annoying, but > > > I > > > don't know > > > how to debug it to find its cause. > > > > > > The issue is that sometimes Konqueror completely freezes: none of > > > its > > > windows > > > respond to mouse or keyboard. The only way to go on is to kill > > > it. > > > It's not a > > > frequent issue: it usually happens once a day or so. Once it has > > > happened, > > > however, it's likely to happen again in a short time. > > > > > > I attach a backtrace by attaching gdb to the Konqueror instance > > > once > > > the > > > freeze happens. As you can see, it contains almost nothing from > > > Konqueror > > > itself: just two calls near the bottom, the last of which is a > > > call > > > to > > > QApplication::exec(). All other function calls are either inside > > > KDE > > > Frameworks or Qt: I'd almost think this is not a problem with > > > Konqueror if it > > > were not for the fact that I'm only experiencing the issue with > > > Konqueror. > > > > Are you sure freeze happens in that thread? > > > > The stacktrace is from the rendering thread. Does Konqueror window > > get > > "grayed out" by KWin when it freezes? If it doesn't I'd think the > > freeze happens in another thread. > > Thanks for the answer. No, the Konqueror window doesn't look grayed > out: it > looks completely normal to the point that often I don't realize it > has frozen > until I try to interact with: only at that point I notice that all > parts of > the UI don't respond in any way yo mouse or keyboard. If I minimize > the > window, then restore it, its contents aren't drawn so that it shows > the > contents of the previously active window. > > I attach a new backtrace with all threads. I still can't see anything > related > to Konqueror. The only thing I can notice is a mention of QDBus in > thread 67, > but I still don't know what information to get from it.
Sorry, I looked at it, but no idea either. Idk the Konqueror's code though. Does Konqueror experience high CPU load when that happens? If it doesn't that's probably a hang in one of those poll()ing or one locked on a mutex — probably a thread waits for some event that never happens. In this case it's kind of hard to determine which thread is stuck. I imagine it should be the thread that processes input events, but Idk which one is that. What I'd suggest to do next is to report a bug for Konqueror with your findings and write that you're open to do more research but kind of stuck. I think actual developers of Konqueror may have more chance to give a useful advice from the stacktrace (or other context). P.S.: if you do find the problematic thread blocked on a mutex and it's unclear how the mutex ended up locked, I recommend using `rr` project to record Konqueror execution up to the moment bug happens. `rr replay` will pop up a `gdb` for you, where you can execute both forward and backward (with `reverse-continue`, `rc` command), and set watchpoints on variables to then move back in time to see when they were changed. An immensely useful tool for debugging thread/data races. > > > > > > Given the randomness of the freezes and the fact that the > > > backtrace > > > contains > > > almost no Konqueror-specific calls, I really have no ideas on how > > > to > > > proceed to > > > debug the issue, and I really don't even know what to search on > > > the > > > web. Do > > > you have any advice? > > > > > > Thanks in advance > > > > > > Stefano
