1862683 - Signed/unsigned char breakage with GCC 12 on aarch64

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect, P3)

Description

[David Turner]

Steps to reproduce:

• Start with an aarch64 Debian Bookworm system
• Install Rust 1.71.0 and cbindgen 0.26.0
• Try to build Firefox 119.0 using system libraries, without bootstrapping dependencies (I'm using the Debian packaging scripts at https://salsa.debian.org/mozilla-team/firefox)

(It's tricky to give a precise reproducer because I'm using sbuild in a customised schroot. If necessary I can try to narrow it down a bit)

Actual results:

I get some exciting C++ compile errors, summarised as:

/<<PKGBUILDDIR>>/build-browser/dist/include/mozilla/dom/TypedArray.h:976:48: error: no matching function for call to ‘mozilla::dom::TypedArray<JS::TypedArray<JS::Scalar::Int8> >::ProcessFixedData(mozilla::dom::TestInterface::PassUnionWithArrayBuffer(const mozilla::dom::UTF8StringOrArrayBuffer&)::<lambda(const mozilla::Span<unsigned char>&)>&) const’                                                                       
  976 |             std::forward<Processor>(aProcessor));                       
      |                                                ^                        
/<<PKGBUILDDIR>>/build-browser/dist/include/mozilla/dom/TypedArray.h:655:46: note: candidate: ‘template<class Processor> mozilla::dom::TypedArray_base<ArrayT>::ProcessReturnType<Processor> mozilla::dom::TypedArray_base<ArrayT>::ProcessFixedData(Processor&&) const [with ArrayT = JS::TypedArray<JS::Scalar::Int8>]’
  655 |   [[nodiscard]] ProcessReturnType<Processor> ProcessFixedData(          
      |                                              ^~~~~~~~~~~~~~~~           
<snip>
/<<PKGBUILDDIR>>/dom/bindings/test/TestBindingHeader.h:737:56:   required from here
/<<PKGBUILDDIR>>/build-browser/dist/include/mozilla/dom/TypedArray.h:583:78: error: no match for call to ‘(mozilla::dom::TestInterface::PassUnionWithArrayBuffer(const mozilla::dom::UTF8StringOrArrayBuffer&)::<lambda(const mozilla::Span<unsigned char>&)>) (mozilla::Span<signed char, 18446744073709551615>)’
  583 |   template <typename Processor, typename R = decltype(std::declval<Processor>()(
      |                                                       ~~~~~~~~~~~~~~~~~~~~~~~^~
/<<PKGBUILDDIR>>/build-browser/dist/include/mozilla/dom/TypedArray.h:583:78: note: candidate: ‘int (*)(const mozilla::Span<unsigned char>&)’ (conversion)
/<<PKGBUILDDIR>>/build-browser/dist/include/mozilla/dom/TypedArray.h:583:78: note:   candidate expects 2 arguments, 2 provided

I'll attach the full build log.

Expected results:

The build should work.

My guess is that Bug 1690111 added some code which implicitly relies on signed chars, which is the case on x86/amd64 but not on armhf/aarch64. I can see that Debian's aarch64/armhf builds worked (https://buildd.debian.org/status/fetch.php?pkg=firefox&arch=arm64&ver=119.0-1&stamp=1698274169&raw=0). I'm guessing this is because they're building on Debian unstable with GCC 13 which implements https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2513r4.html which loosens up some char8_t signedness restrictions, but this is really just a guess.

Comment 1

[David Turner]

Attachment: firefox_119.0-1+rpt2_arm64-2023-11-02T12:49:44Z.build

Comment 2

[David Turner]

I've found out that commenting out the line // APPLY_IMPL(Int8Array) in dom/bindings/TypedArray.h fixes the issue, so it seems like the C++ template/overload resolution around ApplyToTypedArray is going wrong resulting in the ArrayBuffers getting interpreted as having int8_t (AKA signed char) elements which conflicts with the uint8_t (AKA unsigned char) definition of the processor lambda.

As for why I seem the be the only person hitting this, my guess is still that nobody else is building with GCC 12 on aarch64.

Peter: Are you able to shed any light on this as the code was introduced in your commit? I think I've reached the limit of my C++ knowledge.

Comment 3

[Peter Van der Beken [:peterv]]

The line which is causing the issue would be https://searchfox.org/mozilla-central/rev/e94bcd536a2a4caad0597d1b2d624342e6a389c4/dom/bindings/TypedArray.h#646. That calls GetCurrentData() on an ArrayBuffer, which returns a Span<element_type>. element_type is an alias for DataType, which for an ArrayBuffer is defined to be uint8_t. You might want to look at the preprocessed source to figure out why that's not the case for you. I don't think there's anything wrong with the TypedArray code.

Comment 4

[David Turner]

I've managed to narrow down a reproducer to a single file (attached) which I could chuck into godbolt. Turns out it's nothing specific to aarch64 at all, but seems to be a bug specifically in GCC 12.1/12.2 which got fixed in GCC 12.3 (the code works fine on GCC 10, 11, 12.3, 13). The signedness thing is a red herring - the error contains signed char because APPLY_IMPL(Int8Array) comes first. If you put APPLY_IMPL(Uint8Array) first it works fine (because we only have uint8_t processors right now). Seems like something is going wrong with SFINAE.

I've not managed to work out exactly which GCC bug this is (there are quite a lot of GCC 12 regressions fixed in 12.3 and this one is quite subtle). Unfortunately Debian Stable is stuck on GCC 12.2 for the foreseeable future and so won't be able to build Firefox (unless you use mach bootstrap to get a newer compiler). It would be nice if we could include a workaround for this, but I'm pretty sure the fault isn't actually in your code.

Comment 5

[David Turner]

Attachment: 1862683_reproducer.cpp

Comment 6

[Negritas Sergiu, Desktop QA]

Hello! I have tried to reproduce the issue with firefox 121.0a1(2023-09-10) on Ubuntu 22.04, unfortunately I wasn't able to reproduce the issue on my end. Could you please answer the following questions in order to further investigate this isssue.

1. Does this issue happen with a new profile? Here is a link on how to create one: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles
   2.Does this issue happen in the latest nightly? Here is a link from where you can download it: https://www.mozilla.org/en-US/firefox/channel/desktop/
2. Do you have any addons installed? If yes could you please list them?

Comment 7

[David Turner]

This issue occurs when compiling Firefox, so has nothing to do with profiles and add-ons. And Ubuntu 22.04 does not have GCC 12.1 or 12.2 (at least by default) so would not see this issue even when building Firefox from source.

Comment 8

[Negritas Sergiu, Desktop QA]

Thank you for the clarification unfortunately we don't have the hardware to test this issue I will mark with the corresponding flag.

Have a nice day!

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 10

[Hsin-Yi Tsai (she/her) [:hsinyi]]

[domcore-bugbash-triaged] Doing domcore random bug triage - this is not a Firefox/Gecko issue.