Re: Help with debugging a bug in Konqueror

On luned=C3=AC 13 luglio 2026 23:21:13 Ora legale dell=E2=80=99Europa centr=
ale Albert=20
Astals Cid wrote:
> El dilluns, 13 de juliol del 2026, a les 9:39:58 (Hora d=E2=80=99estiu d=
=E2=80=99Europa
>=20
> central), Stefano Crocco va escriure:
> > 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 i=
ts
> > > > 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 ou=
t:
> > it looks completely normal to the point that often I don't realize it h=
as
> > frozen until I try to interact with: only at that point I notice that a=
ll
> > 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
> > > > 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
> >=20
> > I attach a new backtrace with all threads (compressed because of size).=
 I
> > still can't see anything related to Konqueror. The only thing I can not=
ice
> > is a mention of QDBus in thread 67, but I still don't know what
> > information
> > to get from it. Any other ideas?
>=20
> Does it always get stuck in glXSwapBuffers ?
>=20
> That would call for a driver bug possibly?
>=20
> Does using
>=20
> export QT_XCB_FORCE_SOFTWARE_OPENGL=3D1
>=20
> make it not get stuck?
>=20
> Cheers,
>   Albert

Thanks for the avice. I've kept the backtraces of three of these situations=
=20
and all of them show a call to glXSwapBuffers. As soon as I have time, I'll=
 try=20
your suggestion about QT_XCB_FORCE_SOFTWARE_OPENGL even if I fear it would =
be=20
difficult to determine whether it actually prevents the issue, given its=20
randomness. For example, yesterday morning I experienced it several times b=
ut=20
I haven't had it since yesterday afternoon.

Stefano