On lunedì 13 luglio 2026 10:09:21 Ora legale dell’Europa centrale Konstantin Kharlamov wrote: > 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.
Sorry, I should have mentioned before that I am the Konqueror developer (unfortunately, I'm the only one). Konqueror itself only uses the GUI thread, so all other threads are used by either the KDE Frameworks or by Qt. Thanks for your suggestion about rr: i'll look into it. Stefano
