2091237 - Nightly 162.0a1 (20261109214446) does not start on macOS 27.0.1: dyld rejects libnss3.dylib (mis-aligned LINKEDIT string pool)

Status: RESOLVED FIXED

(Firefox Build System :: General, defect, P1)

Description

[Raunaq]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:162.0) Gecko/20100101 Firefox/162.0

Steps to reproduce

1. I ran Firefox Nightly 162.0a1, build 20261109092106, on macOS 27.0.1 (build 26A434), on an Apple silicon Mac (Mac14,2, arm64).
2. The app updater applied the partial update to build 20261109214446 on 10 November 2026. The update log ends with "succeeded".
3. I started Nightly.

Update file: firefox-mozilla-central-162.0a1-mac-en-US-20261109092106-20261109214446.partial.mar

Actual results

No window opens. The process exits with code 1.

The command "/Applications/Firefox Nightly.app/Contents/MacOS/firefox" --version prints this text:

XPCOMGlueLoad error for file /Applications/Firefox Nightly.app/Contents/MacOS/libnss3.dylib:
dlopen(/Applications/Firefox Nightly.app/Contents/MacOS/libnss3.dylib, 0x0109): tried: '/Applications/Firefox Nightly.app/Contents/MacOS/libnss3.dylib' (mis-aligned LINKEDIT string pool, fileOffset=0x00290804), '/System/Volumes/Preboot/Cryptexes/OS/Applications/Firefox Nightly.app/Contents/MacOS/libnss3.dylib' (no such file), '/Applications/Firefox Nightly.app/Contents/MacOS/libnss3.dylib' (mis-aligned LINKEDIT string pool, fileOffset=0x00290804)
Couldn't load XPCOM.

Analysis:

dyld on macOS 27 requires that LC_SYMTAB.stroff is 8-byte aligned. In the arm64 slice of libnss3.dylib in build 20261109214446, stroff is 2689028 (0x290804). The remainder of 2689028 divided by 8 is 4.

stroff for the arm64 slice of each Mach-O file in Contents/MacOS (otool -arch arm64 -l <file> | grep stroff):

File 20261109092106 20261109214446
stroff mod 8 stroff mod 8
XUL 181405840 0 180157972 4
libEGL.dylib 76472 0 76468 4
libGLESv2.dylib 4408824 0 4359780 4
libmozavcodec.dylib 2227424 0 2211020 4
libmozavutil.dylib 470784 0 454388 4
libmozinference.dylib 3050984 0 3050948 4
libnss3.dylib 2721816 0 2689028 4
firefox 72240 0 72240 0
libfreebl3.dylib 922336 0 938720 0
libgkcodecs.dylib 7242728 0 7226280 0
liblgpllibs.dylib 156504 0 156496 0
libmozglue.dylib 786152 0 753608 0
libonnxruntime.dylib 10829296 0 10845760 0
libsoftokn3.dylib 352272 0 352288 0

In build 20261109092106, each file has a remainder of 0. In build 20261109214446, seven files have a remainder of 4.

The files of build 20261109214446 are not damaged on the disk:

• codesign --verify --deep --strict on the app exits with code 0.
• spctl -a -vv prints "accepted, source=Notarized Developer ID".
• SHA-256 of libnss3.dylib: 592b7752ecf683bc7a73cff5a2f7a25104e436726893299d90e3321dd3a394ec

Related reports of the same dyld error on macOS 27. These reports name llvm-objcopy --strip-debug as the tool that writes the string table at a 4-byte offset:

• https://github.com/llvm/llvm-project/issues/203678 (fixed by llvm/llvm-project pull request 203680)
• https://github.com/rust-lang/rust/issues/157750

Workaround: install build 20261109092106 from the DMG on archive.mozilla.org.

Not tested: a full install of build 20261109214446 from the DMG.

Expected results

Nightly starts and opens a window. Build 20261109092106 does this on the same machine and the same macOS version.

Comment 1

[Hackbot [:hackbot]]

Attachment: Bug 2091237 - Backport the llvm-objcopy MachO __LINKEDIT alignment fix to clang 22.

Without this fix, llvm-strip/llvm-objcopy in clang 22 can write LC_SYMTAB.stroff (and other __LINKEDIT entries) at 4-byte offsets after it strips symbols. dyld on macOS 27 rejects these files ("mis-aligned LINKEDIT string pool"). Our macOS builds strip with llvm-strip (-x -S), so Nightly broke when the clang 23 update was reverted (e83796ab25d3, Bug 2039813 / Bug 2090871), which put builders back on clang 22. clang 23 and trunk already contain the upstream fix (llvm/llvm-project#203680, 18c1cbce6874), and it applies cleanly to clang 22.

Comment 2

[Stephen A Pohl [:spohl]]

This is fixed by the backout of bug 2072073. An equivalent (identical?) patch to hackbot's change has been added to the patch stack in bug 2072073 and will land alongside the SDK bump to not depend on clang-23 landing at the same time.

Comment 3

[BugBot [:suhaib / :marco]]

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