Help with debugging a bug in Konqueror

Stefano Crocco stefano.crocco at alice.it
Tue Jul 14 07:36:26 BST 2026


On lunedì 13 luglio 2026 23:21:13 Ora legale dell’Europa centrale Albert 
Astals Cid wrote:
> El dilluns, 13 de juliol del 2026, a les 9:39:58 (Hora d’estiu d’Europa
> 
> central), Stefano Crocco va escriure:
> > 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.
> > 
> > > > 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
> > 
> > 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 notice
> > is a mention of QDBus in thread 67, but I still don't know what
> > information
> > to get from it. Any other ideas?
> 
> Does it always get stuck in glXSwapBuffers ?
> 
> That would call for a driver bug possibly?
> 
> Does using
> 
> export QT_XCB_FORCE_SOFTWARE_OPENGL=1
> 
> make it not get stuck?
> 
> Cheers,
>   Albert

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

Stefano




More information about the kde-devel mailing list