www-client/ungoogled-chromium-123*: tabs freeze (javascript issue?) about gentoo-overlay

[thubble]

I applied the following 3 patches and am building now:

• https://github.com/OpenMandrivaAssociation/chromium/blob/master/blink-fonts-shape-result.patch (not sure if this one is actually necessary, but it seems like a good idea).
• https://github.com/OpenMandrivaAssociation/chromium/blob/master/bad-font-gc1.patch
• https://github.com/OpenMandrivaAssociation/chromium/blob/master/bad-font-gc2.patch

Apparently it was caused by this MR: https://chromium-review.googlesource.com/c/chromium/src/+/5262982, so these patches revert it. According to the post-merge comments on that MR, Debian ran into issues as well and it's suspected that it caused a use-after-free bug with libstdc++.

I'll update after building and testing.

[thubble]

Update: I've been using the patched build for about the last hour with no issues. Looks like those patches are the solution.

[thubble]

I applied the 3 patches from OpenMandriva (#333 (comment)), and in initial testing the issue appears to be fixed. I haven't had time to test extensively, but I've opened an closed a couple of dozen sites in tabs without issue - before the patches, I'd pretty reliably get the crash every 5th tab or so.

I didn't make any other changes besides those 3 patches, so I don't think it has anything to do with any other patches from this specific ebuild, or ungoogled chromium. Based on the comments in the original MR that's being reverted (https://chromium-review.googlesource.com/c/chromium/src/+/5262982), the issue seems identical.

The most recent comments in that MR speculate that the issue is a general use-after-free/race condition, and libc++ only coincidentally works because its implementation of std::string works after calling the destructor while libstdc++'s doesn't. Another comment indicates that the MR causes a significant performance regression in speedometer performance as a trade-off for less memory usage, although that might have been mitigated by a subsequent patch.

So given all that, reverting the MR using those OpenMandriva patches might be a good idea regardless - and it does seem to fix the crash for me so far.

[thubble]

I did some searching, it looks like OpenMandriva has some patches that fix a similar issue: OpenMandrivaAssociation/chromium@2a93c4c#diff-c431c56ebdda82c62b8a1002034e509fedad8c95f86b4ea29a7ef3c8ad9afd52

Patches are quite large, but I'm going to try applying them and building. I'll let you know if it fixes the issue.

[PF4Public]

Is this freezing only happening on hardened GCC or a general issue with the latest version?

General issue, unrelated to GCC "hardenness".

[PF4Public]

I've bumped 124 and pulled in patches from Debian. Haven't finished building though.

[PF4Public]

124.0.6367.155 builds and runs for me, so I'm marking it stable and close this issue.

[mrusme]

Confirming here as well, tab crashes appear to be gone now. Thank you!

[thubble]

I'm having the same issue with version 123.0.6312.122_p1. I skipped version 122 but did not have the issue on 121.

Use flags: USE="X clang cups hevc kerberos official optimize-thinlto optimize-webui pgo proprietary-codecs pulseaudio system-crc32c system-double-conversion system-ffmpeg system-harfbuzz system-libevent system-libusb system-openh264 system-openjpeg system-snappy system-woff2 system-zstd thinlto vaapi wayland widevine -bluetooth -cfi -convert-dict -cromite -custom-cflags -debug -enable-driver -gtk4 -hangouts -headless -libcxx -nvidia -override-data-dir -pax-kernel -qt5 -qt6 -screencast (-selinux) -system-abseil-cpp -system-av1 -system-brotli -system-icu -system-jsoncpp -system-libvpx -system-png -system-re2" ABI_X86="(64)" L10N="-af -am -ar -bg -bn -ca -cs -da -de -el -en-GB -es -es-419 -et -fa -fi -fil -fr -gu -he -hi -hr -hu -id -it -ja -kn -ko -lt -lv -ml -mr -ms -nb -nl -pl -pt-BR -pt-PT -ro -ru -sk -sl -sr -sv -sw -ta -te -th -tr -uk -ur -vi -zh-CN -zh-TW"

I'm also seeing the following errors in dmesg, which correlate with the tab crashes:

[525339.446815] Chrome_ChildIOT[3049358]: segfault at 1 ip 00005f61d4b41f53 sp 00005f61b41fd930 error 4 cpu 0 in chrome[5f61d4108000+b16f000] likely on CPU 0 (core 0, socket 0)
[525339.446825] Code: 18 48 8b 46 18 8b 58 0c 8b 68 10 8b 48 14 48 c7 04 24 91 00 00 00 8a 05 7c f6 01 0b 48 c1 e3 20 83 e5 06 48 09 cb 84 c0 75 28 <48> 8b 07 ff 50 18 83 fd 04 75 12 48 c7 04 24 91 00 00 00 8a 05 55
[567470.934670] chrome[3045596]: segfault at 0 ip 00005f61da09742f sp 00007ffc57805c30 error 4 cpu 3 in chrome[5f61d4108000+b16f000] likely on CPU 3 (core 3, socket 0)
[567470.934680] Code: ff 25 e0 0f 00 00 4d 8b a7 00 10 00 00 0f 18 0e 4d 8d b4 07 00 10 00 00 41 0f b6 46 1e 83 e0 3f c1 e0 05 49 29 c6 41 0f 18 0e <41> 80 3c 24 02 0f 84 1c 03 00 00 41 80 7c 24 04 00 74 59 48 89 d8

[mrusme]

I appear to be having a similar issue and reading this thread I also checked my dmesg to find the following:

[175463.419651] chrome[23178]: segfault at 0 ip 00005575b96a0aff sp 00007ffc0c07b650 error 4 in chrome[5575b3f5a000+c98d000] likely on CPU 0 (core 0, socket 0)
[175463.419666] Code: 00 10 00 00 0f 18 0e 48 c1 e0 05 4d 8d b4 07 00 10 00 00 41 0f b6 84 07 1e 10 00 00 83 e0 3f 48 c1 e0 05 49 29 c6 41 0f 18 0e <41> 80 3c 24 02 0f 84 67 01 00 00 41 80 7c 24 04 00 74 5d 48 89 d8

[PF4Public]

I can also reproduce this issue, it doesn't happen immediately and I didn't notice it :(

Could it be me removing those two lines?

gentoo-overlay/www-client/ungoogled-chromium/files/chromium-123-libstdc++.patch

Lines 550 to 560 in 80a8f2a

	--- a/third_party/blink/common/interest_group/auction_config_mojom_traits.cc
	+++ b/third_party/blink/common/interest_group/auction_config_mojom_traits.cc
	@@ -207,8 +207,6 @@
	!data.ReadAllBuyersPrioritySignals(&out->all_buyers_priority_signals) ||
	!data.ReadAuctionReportBuyerKeys(&out->auction_report_buyer_keys) ||
	!data.ReadAuctionReportBuyers(&out->auction_report_buyers) ||
	- !data.ReadAuctionReportBuyerDebugModeConfig(
	- &out->auction_report_buyer_debug_mode_config) ||
	!data.ReadRequiredSellerCapabilities(
	&out->required_seller_capabilities) ||
	!data.ReadRequestedSize(&out->requested_size) ||

[r7l]

I am also having this issue with hardened GCC. Is this freezing only happening on hardened GCC or a general issue with the latest version? I don't have it on 121.

[PF4Public]

Sorry everyone, was very busy.