Re: Help with debugging a bug in Konqueror

On luned=C3=AC 13 luglio 2026 10:09:21 Ora legale dell=E2=80=99Europa centr=
ale Konstantin=20
Kharlamov wrote:
> 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 c=
entrale you
> >=20
> > 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  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.
> >=20
> > 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.
>=20
> Sorry, I looked at it, but no idea either.
>=20
> Idk the Konqueror's code though.
>=20
> 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 ha=
ppens.
> 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.
>=20
> 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).
>=20
> 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=20
(unfortunately, I'm the only one).

Konqueror itself only uses the GUI thread, so all other threads are used by=
=20
either the KDE Frameworks or by Qt.=20

Thanks for your suggestion about rr: i'll look into it.

Stefano