Summary: | dev-qt/qtwebengine-5.15.2_p20210224: ERROR:network_service_instance_impl.cc(286)] Network service crashed, restarting service. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | 12101111 <w12101111> |
Component: | Current packages | Assignee: | Qt Bug Alias <qt> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | cafaia, gentoo.org, jstein, stkabugs |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://bugreports.qt.io/browse/QTBUG-91715 | ||
See Also: |
https://bugs.archlinux.org/task/69902 https://bugs.gentoo.org/show_bug.cgi?id=773040 |
||
Whiteboard: | fix: ensure timestamp of gentoo >=2021-03-12 20:45; emerge -1q dev-qt/qtwebengine | ||
Package list: | Runtime testing required: | --- | |
Attachments: |
emerge --info from musl system
emerge --info from glibc system build.log from glibc system |
Description
12101111
2021-03-02 07:23:30 UTC
Created attachment 688974 [details]
emerge --info from musl system
Created attachment 688977 [details]
emerge --info from glibc system
Created attachment 688992 [details]
build.log from glibc system
Please build with GCC then. (In reply to Andreas Sturmlechner from comment #4) > Please build with GCC then. All other qt libraries of my system are linked against libc++, so building qtwebengine with gcc will get lots of c++ abi error. The toolchain used in chromium upstream is clang/libc++. It shouldn't be the problem here. We'll have to assume it is a build-with-clang problem then, anyway, as long as it is not reproduced with GCC. This bug hits kmail 20.12.2 and konqueror 20.08.3, not displaying emails or webpages. downgrade to dev-qt/qtwebengine-5.15.2 works. I'm not using clang wittingly. (firefox&mesa are the only ones depending on clang equery says, never switched from gcc away I believe, don't know how). The reason is still unknown but I find a workaround to make it work at least: run with --single-process. However not all program accept this option. screenshot: https://github.com/12101111/overlay/issues/13 Since there are some reports from archlinux, this is not a toolchain or kernel issue. And I don't think this is a network issue, because as the chromium document say, --enable-features=NetworkServiceInProcess make the network service run in main process, and this do make the network part works, but the program is still broken. I've hit the same issue, my primary browser being Konqueror. The problem is that compiling qtwebengine takes very long on my system. Just one thing I noticed while downgrading, as of this moment still in progress: [ebuild UD ] dev-qt/qtwebengine-5.15.2:5/5.15::gentoo [5.15.2_p20210224:5/5.15::gentoo] USE="alsa pulseaudio system-ffmpeg system-icu widgets -bindist -debug -designer -geolocation -kerberos -test (-jumbo-build%*)" 0 KiB The apparent difference is that 5.15.2_p20210224 is a USE="jumbo-build", while 5.15.2 apparently is not. Also I remember that in the past there were issues with USE="system-icu" and USE="system-ffmpeg", but recently this worked again... Would using clang solve the issue? It's already on my system, not only for Firefox. I've decided to go with ~amd64 sys-devel/clang:11 (ACCEPT_KEYWORDS) for accelerated video output over dev-libs/intel-neo... It'd be interesting to know what window manager affected people are using. From the information I've gathered[1] so far, all people affected by this are either on i3wm or bspwm (yet [2] mentions seeing it on KDE Plasma, while someone in the qutebrowser repository said they could only reproduce after switching from Plasma to i3). [1] https://github.com/qutebrowser/qutebrowser/issues/6235#issuecomment-793099273 [2] https://github.com/12101111/overlay/issues/13#issuecomment-792458441 I have same issue, after upgrade to qtwebengine-5.15.2_p20210224, rstudio can't work, print "ERROR:network_service_instance_impl.cc(286)] Network service crashed, restarting service". Run "rstudio --single-process" works for me. I use gcc and kde. I only even have Plasma installed, oo other window manager. I also have Wayland available and sometimes tested KDE Plasma with Wayland, but it wasn't satisfactory yet, but it's a fact that I did switch between Plasma/X11 and Plasma/Wayland sometimes. Not recently though. I don't know how to pass option --single-process to WebEngine, because Konqueror doesn't support that option. I've saved the two builds now, following https://wiki.gentoo.org/wiki/Binary_package_guide, so now I'm able to quickly switch between 5.15.2 and 5.15.2_p20210224, which took around 16hrs to build on my old and slow system. The later I tried without jumbo-build (but again with system-ffmpeg and system-icu), but didn't change anything, still gives the same error. I think this might be related to the locale somehow. With my default LANG=en_US.UTF-8 I can't reproduce, but with LANG=en_DK.UTF-8 I can (on Archlinux though). Will dig into it more tomorrow or so. FYI, I now reported this upstream: https://bugreports.qt.io/browse/QTBUG-91715 I found a better workaround (--single-process is bad from a stability/security perspective): * Find out the locale .pak name matching your locale in /usr/share/qt/translations/qtwebengine_locales/ (path from my Archlinux system, might be slightly different on Gentoo). This is usually the first part of your locale, except for en_DK.UTF-8 (or other en_* except en_US and en_GB) where you'll need to pick either "en-GB" or "en-US". Other special cases might be es-419, pt-BR, pt-PT, zh-CN and zh-TW. * Start the affected application with the according --lang argument, e.g. --lang=de * If your application doesn't accept/forward those arguments, set QTWEBENGINE_CHROMIUM_FLAGS=--lang=de in your environment instead (for qutebrowser, use --qt-flag or its qt.args setting) (In reply to Florian Bruhin from comment #14) > FYI, I now reported this upstream: > https://bugreports.qt.io/browse/QTBUG-91715 > > I found a better workaround (--single-process is bad from a > stability/security perspective): > > * Find out the locale .pak name matching your locale in > /usr/share/qt/translations/qtwebengine_locales/ (path from my Archlinux > system, might be slightly different on Gentoo). This is usually the first > part of your locale, except for en_DK.UTF-8 (or other en_* except en_US and > en_GB) where you'll need to pick either "en-GB" or "en-US". Other special > cases might be es-419, pt-BR, pt-PT, zh-CN and zh-TW. > * Start the affected application with the according --lang argument, e.g. > --lang=de > * If your application doesn't accept/forward those arguments, set > QTWEBENGINE_CHROMIUM_FLAGS=--lang=de in your environment instead (for > qutebrowser, use --qt-flag or its qt.args setting) Many thanks! I can confirm https://codereview.qt-project.org/c/qt/qtwebengine/+/338355 fix this bug. FWIW the patch still has issues - it causes a crash for me (without problems before) and for someone else too, see the comments on the review page. I'd recommend waiting until it's been fixed and merged upstream. A proper fix was now merged upstream: https://code.qt.io/cgit/qt/qtwebengine.git/commit/?h=5.15&id=199ea00a9eea13315a652c62778738629185b059 (In reply to Florian Bruhin from comment #18) > A proper fix was now merged upstream: > https://code.qt.io/cgit/qt/qtwebengine.git/commit/?h=5. > 15&id=199ea00a9eea13315a652c62778738629185b059 Thanks a lot for keeping us up to date here! https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=286732e1677d672669f19607f1db62780c62d746 commit 286732e1677d672669f19607f1db62780c62d746 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2021-03-12 17:08:45 +0000 dev-qt/qtwebengine: Fix runtime crash with certain locales Due to the pain a revbump will cause and only a minority of users affected, the patch is applied in place and we will ask affected users to rebuild. Reported-by: 12101111 <w12101111@outlook.com> Thanks-to: Florian Bruhin <gentoo.org@the-compiler.org> If you are affected by this bug, please sync and check: # emerge --sync # emerge --info | grep ^Timestamp Timestamp of repository gentoo: Fri, 12 Mar 2021 20:45:02 +0000 ^ you are good to go to rebuild: # emerge -1q dev-qt/qtwebengine Worked, thanks! Worked on my system. Thank you I think we can consider this fixed. |