Created attachment 261328 [details] qutebrowser -T --debug output Hello, qutebrowser on FreeBSD-14.3-RELEASE works fine on xorg, but on wayland it immediately crashes/fails to start. It starts to draw a window and dies. It started doing this the day before yesterday, I suspect there's something wrong with qt6-webengine or similar package, because a lot of qt6-...... and py311-qt6-...... packages were upgraded yesterday. [I] ~ $ freebsd-version -kru 14.3-RELEASE 14.3-RELEASE 14.3-RELEASE [I] ~ $ qutebrowser --version qutebrowser v3.5.1 Git commit: Backend: QtWebEngine 6.9.1 based on Chromium 130.0.6723.192 with security patches up to 136.0.7103.114 (plus any distribution patches) (source: api) Qt: 6.9.1 This is the error reported: [37029:38532953686024:0616/072016.456146:FATAL:check.cc(361)] Check failed: false. NOTREACHED log messages are omitted in official builds. Sorry! fish: Job 1, 'qutebrowser' terminated by signal SIGTRAP (Trace or breakpoint trap) It does this even with a newly created user, with -T flag. The entire qutebrowser -T --debug output is in the attachment. The qutebrowser developer "The Compiler" redirected me here, as it has something to do with FreeBSD/qtwebengine.
(In reply to Matt K from comment #0) Hi Matt, thanks for report. I wonder how familiar are you the ports framework? Maybe you could adopt a fix from 286635 to qt6-webengine? Looks like it uses its bundled copy of chromium, and the fix could be applied to src/3rdparty/chromium/ui/ozone/platform/wayland/host/wayland_frame_manager.cc. I could probably do it, but I don't use wayland, so cannot test it.
I have the same bug. I am going to test the proposed solution, but it will take some time: qt6-webengine is long to compile...
Created attachment 261433 [details] Unsuccessful patch Thanks to ccache, testing has been faster than expected. I have tested unsuccessfully the attached patch. Same bug as before, nothing changed.
Is this still relevant? I was finally setup a Wayland environment for myself. It works for me. qutebrowser v3.5.1 Git commit: Backend: QtWebEngine 6.9.1 based on Chromium 130.0.6723.192 with security patches up to 136.0.7103.114 (plus any distribution patches) (source: api) Qt: 6.9.1 (compiled 6.8.3) The major difference I see is it's mentioning Qt: 6.9.1 (compiled 6.8.3), I'm not sure why it shows "(compiled 6.8.3)". FWIW, I'm using the official package repo for these packages.
(In reply to Roman Bogorodskiy from comment #4) I will test again the port as soon as possible. Have you taken care to set QT_QPA_PLATFORM=waylan in your environment when running qutebrowser?
(In reply to Lorenzo Salvadore from comment #5) Typo: I meant QT_QPA_PLATFORM=wayland of course
(In reply to Lorenzo Salvadore from comment #6) > Typo: I meant QT_QPA_PLATFORM=wayland of course No, I didn't use it, and now with it it also segfaults for me. Sorry, I'm a total wayland noob.
(In reply to Lorenzo Salvadore from comment #6) I have it set up to: [I] ~ $ echo $QT_QPA_PLATFORM wayland;xcb it's segfaulting the same way even if I set it to 'wayland'
QTWEBENGINE_CHROMIUM_FLAGS="--ignore-certificate-errors --no-sandbox --disable-gpu" qutebrowser this setting works for me
I see the same problem with other QtWebEngine apps, e.g. Falkon, KMail. They all fail to start under Plasma Wayland, but run successfully with QTWEBENGINE_CHROMIUM_FLAGS="--disable-gpu".
*** Bug 285619 has been marked as a duplicate of this bug. ***
The problem is GPU/driver dependent: the same packages work for me under sway/NVidia and crash on the other system with Intel graphics.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=cd8a2d391eb83ac123c0e22bd27ba8c77064f3a3 commit cd8a2d391eb83ac123c0e22bd27ba8c77064f3a3 Author: Baptiste Daroussin <bapt@FreeBSD.org> AuthorDate: 2026-04-08 11:36:11 +0000 Commit: Baptiste Daroussin <bapt@FreeBSD.org> CommitDate: 2026-04-08 11:55:47 +0000 www/qt6-webengine: fix running under wayland When starting, chromium calls GpuFence::Wait() which was not implemented on FreeBSD, on linux is calls sync_wait which does not exist on FreeBSD. Hopefully drm sync fence fds do support polling and it seems to do the trick. While here tell chromium we don't have sync_fence_info() so it does not try to go further at the risk of reaching another NOTREACH() which would trigger a crash PR: 287599 .../Makefile | 0 .../distinfo | 0 .../files/patch-CMakeModules_CompilerFlags.cmake | 0 .../files/patch-src_main.cpp | 0 .../files/patch-src_player_CodecsComponent.cpp | 0 .../files/patch-src_system_SystemComponent.cpp | 0 .../files/patch-src_system_SystemComponent.h | 0 .../pkg-descr | 0 .../pkg-plist | 0 ...rc_3rdparty_chromium_ui_gfx_gpu__fence.cc (new) | 40 ++++++++++++++++++++++ 10 files changed, 40 insertions(+)
(In reply to commit-hook from comment #13) Isn't PORTREVISION bump needed for www/qt6-webengine to be rebuilt on pkg build cluster? This is for runtime fix, not build fix. And following commit upgraded multimedia/jellyfin-desktop but not www/qt6-webengine.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=fbb8b4880d68baab53928de9cf4caecfea559668 commit fbb8b4880d68baab53928de9cf4caecfea559668 Author: Max Brazhnikov <makc@FreeBSD.org> AuthorDate: 2026-04-08 15:37:37 +0000 Commit: Max Brazhnikov <makc@FreeBSD.org> CommitDate: 2026-04-08 15:37:37 +0000 www/qt6-webengine: Rebuild after previous commit PR: 287599 www/qt6-webengine/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
(In reply to commit-hook from comment #15) Thanks!