On lunedì 13 luglio 2026 10:29:49 Ora legale dell’Europa centrale Konstantin Kharlamov wrote: > On Mon, 2026-07-13 at 10:20 +0200, Stefano Crocco wrote: > > 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). > > Oh, sorry! > > > Konqueror itself only uses the GUI thread, so all other threads are > > used by > > either the KDE Frameworks or by Qt. > > You know what, just an experiment, try running with software-based GPU > driver via `LIBGL_ALWAYS_SOFTWARE=1`, just to see if it'd change > anything. If it does that may point at something related to rendering > 🤔
Thanks for the suggestion. The main difficulty is the randomness of the problem: there have been days when it didn't happen so that I hoped it has disappeared after updating some library (I use Gentoo and update my system every day), only to have it reappear after another day or two. Stefano
