www-client/ungoogled-chromium-bin: segfault / tab crash when opening Element web

[zomgroflcopter]

Everytime I try to open any Element web tab I can always get it to crash with the usual "Aw, snap" graphical error and a segfault logged in dmesg. Nothing is visible in console stdout logs.

URL to reproduce: https://app.element.io/#/room/#termux_termux:gitter.im

chrome[17339]: segfault at 0 ip 0000000000000000 sp 00007ffe7cdeba28 error 14 likely on CPU 6 (core 3, socket 0)
Code: Unable to access opcode bytes at 0xffffffffffffffd6.

I tested this with all the currently available ungoogled-chromium-bin versions (those being: 128.0.6613.137, 129.0.6668.70 and 129.0.6668.89) and I can reproduce this on all of them. Worth nothing: I have another machine I haven't updated in a while with 124.0.6367.207 and it doesn't happen, tab opens correctly.

I have no idea on how to debug this further so I'm reporting this just to know if someone else can reproduce it or just for some hints on how to investigate this more.

[PF4Public]

I can reproduce this on a non-bin version. Might be helpful to build a debug version. It might be also a good idea to try another ungoogled-chromium binary (perhaps even Windows' one) to try and reproduce this issue there.

Unfortunately I'm very limited with my internet access and available computing power, so cannot tell right away when/if I could investigate it further.

[alopatindev]

I also reproduce it on www-client/ungoogled-chromium-bin-129.0.6668.89, but cannot reproduce on 129.0.6668.70-1-1 from flatpak.

This might somehow relate to some of the non-system fonts rendering. Here's another example: https://fonts.google.com/noto/specimen/Noto+Color+Emoji

[PF4Public]

Riiiigggght! If it has something to do with font rendering, I can speculate that Fontations is insufficiently good removed here:

gentoo-overlay/www-client/ungoogled-chromium/ungoogled-chromium-129.0.6668.89_p1.ebuild

Lines 471 to 480 in f1283d3

	"${FILESDIR}/chromium-129-fontations.patch"
	"${FILESDIR}/chromium-129-no-link-builtins.patch"
	"${FILESDIR}/restore-x86-r2.patch"
	"${FILESDIR}/chromium-127-separate-qt56.patch"
	"${FILESDIR}/ai_context_bound_object_set-variant.patch" #130+
	)
	ewarn
	ewarn "Following features are disabled:"
	ewarn " - Fontations Rust font stack"

[zomgroflcopter]

@PF4Public

I can reproduce this on a non-bin version. Might be helpful to build a debug version. It might be also a good idea to try another ungoogled-chromium binary (perhaps even Windows' one) to try and reproduce this issue there.

Good idea. I'll try reproducing this on other versions too as soon as I can. I don't have access to good compute at the moment either so I can't build a debug version right now unfortunately...

@alopatindev

This might somehow relate to some of the non-system fonts rendering. Here's another example: https://fonts.google.com/noto/specimen/Noto+Color+Emoji

I think this is actually a separate issue. I tried blocking remote fonts with uBlock and that actually fixes the issue on the page you sent. Doing the same on Element web has no effect, still crashes.

[brianpardy]

I can reproduce the same "Aw, snap" crash with www-client/ungoogled-chromium-129.0.6668.100_p1.ebuild on https://fonts.google.com/noto/specimen/Noto+Color+Emoji

In case it's relevant, I do have media-fonts/noto-emoji-20231130-r1 installed and they appear to work fine on, for example, auto1111 stable-diffusion webui.

[PF4Public]

It could help of someone could build a debug version and obtain a backtrace from a crash.

[brianpardy]

I attempted to build with debug -official but received errors in header files from multiple files in obj/base/base/, so unfortunately I can't help with a debug build at this time.

In file included from ../../base/files/file_path.cc:27:
In file included from ../../base/trace_event/base_tracing.h:19:
In file included from ../../base/trace_event/interned_args_helper.h:16:
In file included from ../../base/trace_event/trace_event.h:27:
In file included from ../../base/trace_event/trace_log.h:30:
In file included from ../../base/trace_event/trace_config.h:20:
In file included from ../../base/trace_event/trace_config_category_filter.h:13:
In file included from ../../base/values.h:30:
../../base/value_iterators.h:48:3: error: defaulted definition of default constructor cannot be mark
ed constexpr before C++23
48 | constexpr dict_iterator() = default;
| ^
../../base/value_iterators.h:103:3: error: defaulted definition of default constructor cannot be mar
ked constexpr before C++23
103 | constexpr const_dict_iterator() = default;
| ^

[PF4Public]

@brianpardy debug flag was often malfunctioning, but you don't need to build it that way, -ggdb3 (as suggested on https://wiki.gentoo.org/wiki/Debugging) should suffice. Besides, debug adds other codepaths, which could potentially make debugging even harder.

[Kawanaao]

@brianpardy debug flag was often malfunctioning, but you don't need to build it that way, -ggdb3 (as suggested on https://wiki.gentoo.org/wiki/Debugging) should suffice. Besides, debug adds other codepaths, which could potentially make debugging even harder.

Enabling the -ggdb3 flag also causes issues. With Electron, this led to significant problems. LLD failed to detect the V8 JSON tracer for some reason. It appears there's a mechanism monitoring whether debug symbols are enabled, which makes me want to throw something at it which may interfere with the build process.

[PF4Public]

Enabling the -ggdb3 flag also causes issues.

Are you speaking for electron? Could be. Chromium - unlikely. I've built it that way many times without issues.