Help with debugging a bug in Konqueror

[Konstantin Kharlamov]

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