qtwebengine 6.6.2 hangs?

[ColonelPhantom]

Hi everyone, noob here

I recently installed Gentoo including all the KDE 6 release candidate stuff and it was working quite well. However, the ebuilds were modified to require Qt 6.6.2. That would be fine, except 6.6.2 was still in testing, so I unmasked them. This also meant building qtwebengine myself (ouch, my poor CPU).

This would all be fine, but now, any program that depends on qtwebengine seems to hang shortly after starting. This is the case for KMail, Qutebrowser, and even akonadiconsole.

At first I thought the culprit was me enabling -g globally, so I disabled that and rebuilt qtwebengine (ouch 2). Unfortunately, no dice.

Anyone else here with Qt 6.6.2 unmasked and having issues with qtwebengine? Or any idea what is going on here, really? It's worth noting that for 6.6.1 I used the binpkg, since it was stable and packaged there at the time I installed Gentoo. So maybe, if I built 6.6.1 myself it might also have been broken

Running KMail in gdb and ^C'ing after it hangs gives me the following (not very informative) backtrace:

[NeddySeagoon]

ColonelPhantom,

Welcome to Gentoo.

The maximum post size is 64k, so you can't post big things. That probably has its origins is segmented addressing. :)
Make friends with wgetpaste. That wakes it easy to past files and command output onto a pastebin. Then you post the URLs so your helpers can find them.

wgetpaste knows about several pastebins. Some accept bigger pastes tan others, so you may need to pick and choose.

[Ionen]

fwiw 6.6.2 will be stabled soon'ish, so the binpkgs should become available a bit after.

As for the hang no idea from just this, first I hear of this happening (qutebrowser with 6.6.2 works fine for me). Are you just using simple "-march=native -O2 -pipe" + gcc/bfd or so? If nothing special, guess could still try without -march (or plain -march=x86-64-v2), qt/chromium can be sensitive w/ some oddball cpus albeit it more typically result in build failures or rare crash/errors rather than hanging, so not too hopeful that it'll help.

[ColonelPhantom]

I uploaded the output of emerge --info qtwebengine to https://bpa.st/5EQQ and as you can see my CXXFLAGS aren't anything too spicy, just what's listed but with "-march=x86-64-v3" instead (my CPU is Zen3).

I also found https://github.com/qutebrowser/qutebrowser/issues/7541 which seems to hint that it's an Nvidia issue, which is plausible. Although the upstream report is a) quite old and b) refers to Nouveau while I use proprietary.

That said, setting "QT_OPENGL=software" seems to render qtwebengine usable again. I added that flag to my KMail desktop file (which is iirc the only qtwebengine program I actually use) and that rendered that workable again.

So it seems to be a graphics issue, at least. Maybe I should try on some other distro that ships Qt 6.6.2 like Arch (I should have my old install laying around), and see if I can reproduce the issue there.

[hurra]

I'm experiencing the same problem here.
Since the update to 6.6.2 of qtwebengine my custom application isn't working anymore. The GUI just freezes right after startup.

I'm also using x11-drivers/nvidia-drivers in version 535.154.05 and i'm currently on kernel 6.6.13-gentoo-dist

Starting the application with
QT_OPENGL="software"
did also work for me as a workaround. Thanks for that

[sam_]

In gdb, please try: thread apply all bt.

Trying strace -f may also help.

[Ionen]

fwiw I am using nvidia as well but without qtwebengine-6.6.2 issues, albeit I'm on =nvidia-drivers-550.54.14 (in ~testing) and haven't tried 535 with 6.6.2 yet (nor wayland, using Xorg).

It's fairly recent but that version is a stable candidate (it's the new production branch) and is due to replace 535. May want to try if it helps (assuming it really is nvidia-related at all), could shorten the stabilization period if it fixes this (not that 550 isn't without regressions, but that's the usual at this point).

Edit:
If it helps, may be worth trying =nvidia-drivers-535.161.07 as well (also in ~testing), it'd be interesting to know if the latest 535 fixes it too -- esp. given that one was due to be stabilized in a few days already.

If driver versions don't help, then will need more to go by like sam noted above (albeit even if I do, unsure if I'll be able to help with this -- maybe could find something related in recent qtwebengine changes with more hints).

[hurra]

i tried all currently available versions of nvidia-drivers in testing, all without success and the same behaviour:

[hurra]

I tried using gdb ( i hav no experiences with gdb)

[yamboo-efi]

I have the same issue in wayland with plasma 6 and nvidia-driver 550.54.14

Falkon freeze on opening, Kmail when render a HTML mesage and also EWS client of akonadi.

For Falkon and Kmail, it can be fixed with any of these env vars:

QT_QPA_PLATFORM=xcb
QTWEBENGINE_CHROMIUM_FLAGS="--disable-gpu-compositing"
QT_OPENGL="software"

I cannot use a previous nvidia-drivers because isn't support my graphics card.

Tried recompiling qtwebengine without vulkan and vaapi, but the result is the same.

For EWS client, when using Oauth2 account, the env can be applied in a terminal and need a akonadictl restart to be applied. I don't tested yet, but a think a whole solution with the less penality are defining the QTWEBENGINE_CHROMIUM_FLAGS env var in plasma session like described in https://userbase.kde.org/Session_Environment_Variables

[Ionen]

If feeling adventurous, could try qtwebengine-6.7.0_rc that just released earlier, it's based on a different version of chromium and changed quite a bit -- so "decent" odds the issue could be gone. Has not been very tested yet though (could hit different issues), and being _rc it's unkeyworded (can accept keywords the whole Qt stack with dev-qt/*:6/6.7.0 **). Otherwise final 6.7.0 is due to release late March or early April depending on delays, there will be a 6.6.3 a bit before it that could potentially have fixes too.

PyQt6-6.6.1 was already patched for 6.7 support, so (at least) qutebrowser should work with it. Plasma 6 is supposedly ok with 6.7, but nobody in Gentoo has really tested that yet.

[Ionen]

exporting QT_OPENGL_NO_SANITY_CHECK=1 may possibly help if this is caused by what I think it was

There's a similar-sounding issue becoming more widespread with wayland+nvidia with Qt6.6.3 that's caused by a change that we had backported to 6.6.2 to fix a plasma 6 issue -- but could be unrelated.

Qt6.7.0 is also released now, and afaik does fix that issue.

[hurra]

[Ionen]

Yeah if it's that issue then 6.6.3 won't help, but 6.7.0 (in ~testing) should. May still be a bit before stabilize 6.7.0 though (if at all, could wait for 6.7.1 depending) given it's a major update and don't want to rush to stabilization.

Believe qutebrowser is considering doing a workaround for 6.6.3, not that it'd fix other packages.

https://github.com/qutebrowser/qutebrowser/issues/8154

Ideally I'd like to know what fixed it in 6.7.0 exactly so could backport but haven't tried to figure that out.

Anyhow, anyone affected can set QT_OPENGL_NO_SANITY_CHECK=1 meanwhile.

[hurra]

Updating to 6.7.0 fixed it for me.