Re: Help with debugging a bug in Konqueror

On Mon, 2026-07-13 at 09:21 +0200, Stefano Crocco wrote:
> On luned=C3=AC 13 luglio 2026 08:49:46 Ora legale dell=E2=80=99Europa cen=
trale 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.
> > >=20
> > > 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.
> > >=20
> > > 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.
> >=20
> > Are you sure freeze happens in that thread?
> >=20
> > 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.
>=20
> Thanks for the answer. No, the Konqueror=C2=A0 window doesn't look grayed
> out: it=20
> looks completely normal to the point that often I don't realize it
> has frozen=20
> until I try to interact with: only at that point I notice that all
> parts of=20
> the UI don't respond in any way yo mouse or keyboard. If I minimize
> the=20
> window, then restore it, its contents aren't drawn so that it shows
> the=20
> contents of the previously active window.
>=20
> I attach a new backtrace with all threads. I still can't see anything
> related=20
> to Konqueror. The only thing I can notice is a mention of QDBus in
> thread 67,=20
> 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 =E2=80=94 probably a thread waits for some event that never happ=
ens.
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.

>=20
> >=20
> > > 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?
> > >=20
> > > Thanks in advance
> > >=20
> > > Stefano