Bug 836604 – dev-qt/qtwebengine-5.15.3_p20220329 fails to build with clang: anonymous non-C-compatible type given name for linkage purposes by typedef declaration after its linkage was computed; add a tag name here to establish linkage prior to definition

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Marco Rebhan 2022-04-01 15:46:13 UTC]

Created attachment 768407 [details]
qtwebengine-5.15.3_p20220329 build log

This is with EXTRA_GN="use_lld=true is_clang=true clang_use_chrome_plugins=false" which fixed the build for previous versions.

Error snippet:

In file included from gen/third_party/blink/renderer/platform/platform_jumbo_64.cc:9:
./../../../../qtwebengine-5.15.3_p20220329/src/3rdparty/chromium/third_party/blink/renderer/platform/text/text_break_iterator_icu.cc:123:15: error: anonymous non-C-compatible type given name for linkage purposes by typedef declaration after its linkage was computed; add a tag name here to establish linkage prior to definition
typedef struct {
              ^
               UTextWithBuffer
./../../../../qtwebengine-5.15.3_p20220329/src/3rdparty/chromium/third_party/blink/renderer/platform/text/text_break_iterator_icu.cc:124:3: note: type is not C-compatible due to this member declaration
  DISALLOW_NEW();
  ^~~~~~~~~~~~~~
../../../../qtwebengine-5.15.3_p20220329/src/3rdparty/chromium/third_party/blink/renderer/platform/wtf/allocator/allocator.h:41:2: note: expanded from macro 'DISALLOW_NEW'
 public:                                                                      \
 ^~~~~~~
./../../../../qtwebengine-5.15.3_p20220329/src/3rdparty/chromium/third_party/blink/renderer/platform/text/text_break_iterator_icu.cc:127:3: note: type is given name 'UTextWithBuffer' for linkage purposes by this typedef declaration
} UTextWithBuffer;
  ^
1 error generated.

[Comment 1 Marco Rebhan 2022-04-01 15:46:42 UTC]

Created attachment 768408 [details]
emerge --info '=dev-qt/qtwebengine-5.15.3_p20220329::gentoo'

[Comment 2 Ionen Wolkens 2022-04-01 16:28:03 UTC]

This snapshot built fine with clang-13 for me, if I were to guess it's clang-14 specific and likely all versions are failing (haven't tried).

[Comment 3 Stephan Hartmann (RETIRED) 2022-04-01 16:38:13 UTC]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261949

[Comment 4 Stephan Hartmann (RETIRED) 2022-04-01 16:41:16 UTC]

Chromium fix: https://crrev.com/c/2819543

[Comment 5 Marco Rebhan 2022-04-01 18:04:26 UTC]

Created attachment 768439 [details, diff]
Patch to fix compilation with clang 14

(In reply to Stephan Hartmann from comment #3)
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261949

That patch worked, thanks! I had to modify it a tiny bit to make it work as a patch for the ebuild, here it is.

[Comment 6 Tiernan Hubble 2022-04-04 01:45:09 UTC]

The patch allowed me to successfully build qtwebengine (5.15.3.9999) with Clang 14, but now QtWebEngineProcess crashes immediately upon loading any site with JavaScript enabled.

This happens even when I build qtwebengine with very modest CFLAGS (-march=native -O2). Although, the build seems to ignore CFLAGS and use Chromium's build system which builds the V8 Javascript engine with -O3.

The only reference I can find to this issue is from this OpenMandriva change (they build everything with clang by default) : https://github.com/OpenMandrivaAssociation/qt5-qtwebengine/commit/cfd17f1ecf4068ef84df2019e965518ae33ad5b2

Unfortunately I don't have a usable stack trace since building qtwebengine with debug symbols seems like a daunting task (at least as far as disk space/memory requirements).

Does anyone have qtwebengine working successfully when built with Clang 14, and if so, would you mind posting your *FLAGS and the qtwebengine version you're using? Thanks!

[Comment 7 Marco Rebhan 2022-04-04 11:16:55 UTC]

(In reply to Tiernan Hubble from comment #6)
> The patch allowed me to successfully build qtwebengine (5.15.3.9999) with
> Clang 14, but now QtWebEngineProcess crashes immediately upon loading any
> site with JavaScript enabled.

I didn't catch this immediately since I pretty much only have qtwebengine because a bunch of stuff needs it where I couldn't care less if it didn't have a browser, but I just tried loading a page in Falkon and am experiencing the same issue with QtWebEngineProcess crashing, but sometimes also ServiceWorker:

> [94063.639758] ServiceWorker t[27335]: segfault at 0 ip 00007f44da7127b4 sp 00007f44b4ff7380 error 4 in libQt5WebEngineCore.so.5.15.3[7f44d9e67000+50a4000]
> [94063.639766] Code: 0e 00 00 48 8d 7b 08 e8 7a 4d b7 ff 48 89 df 48 83 c4 08 5b 5d e9 9c e7 7e 04 48 83 c4 08 5b 5d c3 cc cc cc cc cc 55 48 89 e5 <48> 8b 06 48 89 07 48 85 c0 74 04 f0 83 00 01 5d c3 cc cc cc cc cc

> [94367.034840] traps: QtWebEngineProc[28288] trap int3 ip:7fe47164211c sp:7ffdac233070 error:0 in libQt5WebEngineCore.so.5.15.3[7fe46e5cc000+50a4000]

I'm compiling it with debug symbols right now to see if I can get a stack trace.

[Comment 8 Marco Rebhan 2022-04-04 12:55:48 UTC]

Created attachment 768762 [details]
QtWebEngineProcess backtrace

Here's a backtrace generated with this command (got it from the KDE wiki, https://community.kde.org/Plasma/Debugging, I have no idea how to use gdb beyond the very basics)

% gdb /usr/lib64/qt5/libexec/QtWebEngineProcess 3370 -batch -ex "set logging file QtWebEngineProcess.txt" -ex "set logging on" -ex "continue" -ex "thread apply all backtrace" -ex "quit"

and then loading the YouTube homepage in Falkon which makes the process immediately crash.

Most of it is just waiting threads, but this is very curious:

> Thread 13 "ThreadPoolSingl" received signal SIGSYS, Bad system call.
> [Switching to Thread 0x7fffe50d1640 (LWP 3713)]
> __GI___fstatat64 (fd=-100, file=0x7fffd4000b70 "/sys/fs/cgroup/cpuset/chrome", buf=0x7fffe50d02c8, flag=0) at ../sysdeps/unix/sysv/linux/fstatat64.c:166
> 166	  return INTERNAL_SYSCALL_ERROR_P (r)
> 
> Thread 13 (Thread 0x7fffe50d1640 (LWP 3713) "ThreadPoolSingl"):
> #0  __GI___fstatat64 (fd=-100, file=0x7fffd4000b70 "/sys/fs/cgroup/cpuset/chrome", buf=0x7fffe50d02c8, flag=0) at ../sysdeps/unix/sysv/linux/fstatat64.c:166
> #1  0x00007ffff38c7c8d in base::DirectoryExists(base::FilePath const&) () at /usr/lib64/libQt5WebEngineCore.so.5

Bad system call?

[Comment 9 Miezhiko 2022-04-04 14:54:39 UTC]

did pull request https://github.com/gentoo/gentoo/pull/24897

[Comment 10 Tiernan Hubble 2022-04-04 15:20:04 UTC]

(In reply to Marco Rebhan from comment #8)
> > Thread 13 "ThreadPoolSingl" received signal SIGSYS, Bad system call.
> > [Switching to Thread 0x7fffe50d1640 (LWP 3713)]
> > __GI___fstatat64 (fd=-100, file=0x7fffd4000b70 "/sys/fs/cgroup/cpuset/chrome", buf=0x7fffe50d02c8, flag=0) at ../sysdeps/unix/sysv/linux/fstatat64.c:166
> > 166	  return INTERNAL_SYSCALL_ERROR_P (r)
> > 
> > Thread 13 (Thread 0x7fffe50d1640 (LWP 3713) "ThreadPoolSingl"):
> > #0  __GI___fstatat64 (fd=-100, file=0x7fffd4000b70 "/sys/fs/cgroup/cpuset/chrome", buf=0x7fffe50d02c8, flag=0) at ../sysdeps/unix/sysv/linux/fstatat64.c:166
> > #1  0x00007ffff38c7c8d in base::DirectoryExists(base::FilePath const&) () at /usr/lib64/libQt5WebEngineCore.so.5
> 
> Bad system call?

I got those SIGSYS errors too, but they seem to be handled properly. Likely trying to use cgroups that aren't set up. If you do "continue" in gdb, it will continue executing. You might have to do it a few times. Eventually you'll get a SIGSEGV which is the real error that causes the crash.

How did you get debug symbols? Just adding the "debug" use flag?

[Comment 11 Marco Rebhan 2022-04-04 15:49:29 UTC]

(In reply to Tiernan Hubble from comment #10)
> I got those SIGSYS errors too, but they seem to be handled properly. Likely
> trying to use cgroups that aren't set up. If you do "continue" in gdb, it
> will continue executing. You might have to do it a few times. Eventually
> you'll get a SIGSEGV which is the real error that causes the crash.

Alright, I'll test that.

> How did you get debug symbols? Just adding the "debug" use flag?

I have /etc/portage/env/debugsyms with

> CFLAGS="${CFLAGS} -ggdb"
> CXXFLAGS="${CXXFLAGS} -ggdb"
> FEATURES="${FEATURES} splitdebug compressdebug installsources"

and in /etc/portage/package.env I added

> dev-qt/qtwebengine debugsyms

...though this should give me sources in /usr/src/debug but they aren't there, so maybe installsources is broken for qtwebengine. Debug symbols work though, they'll be in /usr/lib/debug/usr/lib64/libQt5WebEngine*.so.5.15.3.debug. Take a look at https://wiki.gentoo.org/wiki/Debugging, that's where I got this from.

The debug flag isn't helpful here, I think.

[Comment 12 Marco Rebhan 2022-04-04 16:22:52 UTC]

Here's the backtrace I get for the segfault:

> Thread 14 "ServiceWorker t" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7fd1989f8640 (LWP 15827)]
> 0x00007fd1be9e34b4 in blink::MessagePortChannel::MessagePortChannel(blink::MessagePortChannel const&) () from /usr/lib64/libQt5WebEngineCore.so.5
> (gdb) bt
> #0  0x00007fd1be9e34b4 in blink::MessagePortChannel::MessagePortChannel(blink::MessagePortChannel const&) () at /usr/lib64/libQt5WebEngineCore.so.5
> #1  0x00007fd1c19d6b66 in blink::MessagePort::EntanglePorts(blink::ExecutionContext&, blink::WebVector<blink::MessagePortChannel>) ()
>     at /usr/lib64/libQt5WebEngineCore.so.5
> #2  0x00007fd1c19d6990 in blink::MessagePort::EntanglePorts(blink::ExecutionContext&, WTF::Vector<blink::MessagePortChannel, 0u, WTF::PartitionAllocator>) () at /usr/lib64/libQt5WebEngineCore.so.5
> #3  0x00007fd1c0eb3615 in blink::V8ScriptValueDeserializer::Transfer() () at /usr/lib64/libQt5WebEngineCore.so.5
> #4  0x00007fd1c0eb2a4c in blink::V8ScriptValueDeserializer::Deserialize() () at /usr/lib64/libQt5WebEngineCore.so.5
> #5  0x00007fd1c2440a82 in blink::SerializedScriptValueForModulesFactory::Deserialize(scoped_refptr<blink::SerializedScriptValue>, v8::Isolate*, blink::SerializedScriptValue::DeserializeOptions const&) () at /usr/lib64/libQt5WebEngineCore.so.5
> #6  0x00007fd1c0eb20a0 in blink::SerializedScriptValue::Deserialize(v8::Isolate*, blink::SerializedScriptValue::DeserializeOptions const&) ()
>     at /usr/lib64/libQt5WebEngineCore.so.5
> #7  0x00007fd1c243ba25 in blink::DeserializeIDBValue(v8::Isolate*, v8::Local<v8::Object>, blink::IDBValue const*) ()
>     at /usr/lib64/libQt5WebEngineCore.so.5
> #8  0x00007fd1c245858a in blink::IDBRequest::result(blink::ScriptState*, blink::ExceptionState&) () at /usr/lib64/libQt5WebEngineCore.so.5
> #9  0x00007fd1c1de5b77 in blink::V8IDBRequestCallbacks::ResultAttributeGetCallback(v8::FunctionCallbackInfo<v8::Value> const&) ()
>     at /usr/lib64/libQt5WebEngineCore.so.5
> #10 0x00007fd1bf4b75ee in Builtins_CallApiCallback () at /usr/lib64/libQt5WebEngineCore.so.5
> #11 0x00007fd1989f67b0 in  ()
> #12 0x00007fd1989f67e8 in  ()
> #13 0x0000000000000000 in  ()

[Comment 13 Tiernan Hubble 2022-04-05 03:09:47 UTC]

Thanks. I managed to reproduce the exact same stack trace. Now to figure out what Clang 14 is compiling differently that is causing this crash...

[Comment 14 Andreas Sturmlechner 2022-04-05 18:10:04 UTC]

Commit 52f9db05e23cd17e53bbe25369520e820bf2a3b5
dev-qt/qtwebengine: fix building with clang 14

[Comment 15 Tiernan Hubble 2022-04-07 15:13:29 UTC]

Created attachment 769283 [details]
Patches to fix crashes when compiled with clang 14

For anyone still having crashes with qtwebengine compiled with clang 14, I attached a collection of patches I found - backports from more recent Chromium versions. I have all these in /etc/portage/patches/dev-qt/qtwebengine and it fixes the crashes for me. Some of them are changes to the WeakReference<> infrastructure which is where I traced the crash to. I'm not sure which ones are actually necessary - and I'm not all that eager to track it down, I've recompiled qtwebengine more than enough times in the last week! :)

I suspect "0104-Add-fno-delete-null-pointer-checks-to-compiler-flags.patch" might be the only one that's actually necessary (https://crbug.com/1139129 , GCC 6 introduced some weird behaviour without this flag, and I suspect Clang 14 did as well. Recent chromium versions are built with it). "0002-Add-ffp-contract-off-to-compiler-flags.patch" should also be applied for Clang 14 builds because it fixes some subtle floating point errors (https://crbug.com/1235145), although I'm not sure if that's just for Arm?

I'll be keeping all the patches in my local builds regardless - they're performance improvements and potentially fixes for security issues, and they don't seem to be causing any issues in my testing.

I realize this bug is for the clang build error and it's now fixed. I considered creating a separate bug for these patches, but I'm not sure which ones are actually necessary to fix the issue and probably won't have time to attempt to track it down. So I'm just posting these for the benefit of others who had the crashing issue. Obviously, feel free to pull these into the official repo if you want!