Closed Bug 1805809 Opened 2 years ago Closed 2 years ago

relocation R_386_GOTOFF against undefined hidden symbol `tabs_4d51_TabsBridgedEngine_reset' can not be used when making a shared object

Categories

(Toolkit :: UniFFI Bindings, defect)

Firefox 108
defect

Tracking

()

RESOLVED FIXED
110 Branch
Tracking Status
firefox-esr102 --- unaffected
firefox108 --- fixed
firefox109 --- fixed
firefox110 --- fixed

People

(Reporter: glandium, Assigned: glandium)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

On some platforms (happens on Debian i386 and s390x), the build fails with an error like:

relocation R_386_GOTOFF against undefined hidden symbol `tabs_4d51_TabsBridgedEngine_reset' can not be used when making a shared object
/usr/bin/ld: final link failed: bad value

The problem on i386 is that tabs.uniffi.rs doesn't contains tabs_4d51_ prefixes, but tabs_1c79_.

Set release status flags based on info from the regressing bug 1791851

:skhamis, since you are the author of the regressor, bug 1791851, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

There are apparently two problems, one immediate and one theoretical:

  • The hash used in the ffi function prefixes depends on the in-memory properties of ComponentInterface's types.type_definitions.
  • The uniffi_meta::checksum function relies on DefaultHasher, which is not guaranteed to stay the same across versions of rust, so the rust version used to pre-generate toolkit/components/uniffi-js/UniFFIGeneratedScaffolding.cpp might not generate the same hash as the rust version that builds tree.
  • The hash used in the ffi function prefixes depends on the in-memory properties of ComponentInterface's types.type_definitions.

Mmmm that's actually not it. types is not hashed. Its content was the only difference in the output of dbg!() for the hashed value...

This almost looks like another manifestation of bug 1797714 (but Debian i386 being impacted gives me pause)

Oh, the reason it happens on Debian but not on our CI (after all we do have 32-bits Linux builds) is that the Debian build is not cross-compiled, so it's using a x86 rust compiler. I can totally reproduce off the application-services repo on x86_64 after installing a i686 rust compiler (e.g. rustup default stable-i686-unknown-linux-gnu) and removing rust-toolchain.toml (and checking the generated tabs.uniffi.rs).

After digging a little, it turns out the difference comes from the impl Hash for [T], which is called for each Vec, and which does a hasher.write_length_prefix(slice.len()), which translates to hasher.write_usize(slice.len()), which translates to hasher.write(&slice.len().to_ne_bytes()), which will do feed the hasher with 4 bytes on 32-bits and 8 bytes on 64-bits, and with different bytes order depending on the endian, so it is in fact, the same as bug 1797714.

The lesson here is that std::hash::Hash is not meant to be used the way uniffi uses it.

(And the executive summary of the issue is that Firefox fails to build on any platform that is not little-endian 64-bits)

(In reply to Mike Hommey [:glandium] from comment #5)

The lesson here is that std::hash::Hash is not meant to be used the way uniffi uses it.

Yeah - https://github.com/mozilla/uniffi-rs/issues/1393. In the meantime, we decided to prioritize doing the generation at build-time because that would side-step the issue in most cases and also fix other pain points with having the generated code checked in. If that turns out to be tricky we intend fixing it in uniffi first.

The other reason we side-stepped that is because ideally we'd get rid of that hash entirely - in the meantime, uniffi kinda assumes that the uniffi bindgen utility will generally be built using the same compiler that will be used to build the generated code, but I'm not sure whether the above is an example of when this will not be true - ie, it sounds like we might need to fix it in uniffi anyway?

(Removing ni from Sammy as I think we understand what's going on here)

Flags: needinfo?(skhamis)

IIRC, generating the code at build time would be very difficult because of how the integration between C++ and rust code in the build system works. I'm looking at a quick-and-dirty stable hash for Debian.

See Also: → 1797714
Duplicate of this bug: 1797714

(In reply to Mike Hommey [:glandium] from comment #9)

I'm testing applying this on Debian: https://github.com/mozilla/uniffi-rs/compare/main...glandium:uniffi-rs:checksum

Confirmed to work on 32-bits and big-endian. I'll polish it and send a PR.

Assignee: nobody → mh+mozilla
Pushed by mh@glandium.org: https://hg.mozilla.org/integration/autoland/rev/c7aa21aa29c9 Update uniffi to 0.21.1 for more determinism across platforms. r=janerik,supply-chain-reviewers

Duh of course it failed, the checksum changes based on the uniffi version, so we need an update in the generated code in tree.

Attachment #9308782 - Attachment is obsolete: true
Pushed by mh@glandium.org: https://hg.mozilla.org/integration/autoland/rev/2d62469a1741 Update uniffi to 0.21.1 for more determinism across platforms. r=janerik,supply-chain-reviewers
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 110 Branch
Regressions: 1806321
Status: RESOLVED → REOPENED
Flags: needinfo?(mh+mozilla)
Resolution: FIXED → ---
Target Milestone: 110 Branch → ---

hey everyone, thanks for the fix.

Is it possible to backport it to the beta branch?

Never noticed, as I do my test rides of nightly with a cross compiler setup, hence it got away

Pushed by mh@glandium.org: https://hg.mozilla.org/integration/autoland/rev/0c3dbe28af6a Update uniffi to 0.21.1 for more determinism across platforms. r=janerik,supply-chain-reviewers
Status: REOPENED → RESOLVED
Closed: 2 years ago2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 110 Branch
Duplicate of this bug: 1806665

Comment on attachment 9308676 [details]
Bug 1805809 - Update uniffi to 0.21.1 for more determinism across platforms.

Beta/Release Uplift Approval Request

  • User impact if declined: Build failures on 32-bits or big-endian hosts.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Build-time only, no functional change, and if something goes wrong, it does so visibly at build time.
  • String changes made/needed: N/A
  • Is Android affected?: No
Flags: needinfo?(mh+mozilla)
Attachment #9308676 - Flags: approval-mozilla-beta?

Comment on attachment 9308676 [details]
Bug 1805809 - Update uniffi to 0.21.1 for more determinism across platforms.

Beta/Release Uplift Approval Request

  • User impact if declined: If a dot release comes out, it would be good to have this in it too. See beta approval.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky):
  • String changes made/needed:
  • Is Android affected?: No
Attachment #9308676 - Flags: approval-mozilla-release?

Comment on attachment 9308676 [details]
Bug 1805809 - Update uniffi to 0.21.1 for more determinism across platforms.

Approved for Desktop 109.0b6 and Mobile 109.0b3.

Attachment #9308676 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Comment on attachment 9308676 [details]
Bug 1805809 - Update uniffi to 0.21.1 for more determinism across platforms.

Approved for 108.0.2

Attachment #9308676 - Flags: approval-mozilla-release? → approval-mozilla-release+
No longer regressions: 1814373
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: