1950310 - Wrong path to media-plugin-helper.app in macOS artifact build, due to branding

Status: NEW

(Firefox Build System :: General, defect)

Description

[Andreas Pehrson [:pehrsons]]

I can reproduce this on macOS. I assume it's platform specific because the error below is from platform specific code.

With this in my mozconfig (likely enable-debug is irrelevant):

ac_add_options --enable-artifact-builds
ac_add_options --enable-debug

./mach test dom/media/webrtc/tests/mochitests/test_peerConnection_videoCodecs.html fails. Ditto for ./mach wpt testing/web-platform/tests/webrtc/protocol/rtp-demuxing.html. Both rely on GMP and fakeopenh264.

GMP:5 logs say:

1:47.48 GECKO(1550) [Parent 1550: GMPThread]: D/GMP GMPParent[137648100|childPid=0] LoadProcess: for /Users/apehrson/Dev/mozilla-central/obj-aarch64-apple-darwin24.3.0/dist/bin/gmp-fakeopenh264/1.0
 1:47.48 GECKO(1550) [Child 1558: GMPThread]: D/GMP GMP Encode: not initted yet
 1:47.48 GECKO(1550) [Parent 1550: GMPThread]: D/GMP GMPProcessParent::Launch() mLaunchArch: 32
 1:47.48 GECKO(1550) [Parent 1550: GMPThread]: D/GMP GMPProcessParent::FillMacSandboxInfo: plugin dir path: /Users/apehrson/Dev/mozilla-central/obj-aarch64-apple-darwin24.3.0/dist/bin/gmp-fakeopenh264/1.0
 1:47.48 GECKO(1550) [Parent 1550: GMPThread]: D/GMP GMPProcessParent::FillMacSandboxInfo: resolved plugin dir path: /Users/apehrson/Dev/mozilla-central/obj-aarch64-apple-darwin24.3.0/dist/bin/gmp-fakeopenh264/1.0
 1:47.48 GECKO(1550) [Parent 1550: GMPThread]: D/GMP GMPProcessParent::FillMacSandboxInfo: IsPackagedBuild()=false
 1:47.48 GECKO(1550) [Parent 1550: GMPThread]: D/GMP GMPProcessParent::FillMacSandboxInfo: repo dir path: /Users/apehrson/Dev/mozilla-central
 1:47.48 GECKO(1550) [Parent 1550: GMPThread]: D/GMP GMPProcessParent::FillMacSandboxInfo: object dir path: /Users/apehrson/Dev/mozilla-central/obj-aarch64-apple-darwin24.3.0
 1:47.48 GECKO(1550) [Parent 1550, IPC Launch #1] WARNING: posix_spawnp failed: file /builds/worker/checkouts/gecko/ipc/chromium/src/base/process_util_mac.mm:154
 1:47.48 GECKO(1550) [Parent 1550, IPC I/O Parent] WARNING: Failed to launch gmplugin subprocess @posix_spawnp (Error:0): file /builds/worker/checkouts/gecko/ipc/glue/GeckoChildProcessHost.cpp:805
 1:47.48 GECKO(1550) [Parent 1550: GMPThread]: D/GMP GMPParent[137648100|childPid=0] LoadProcess: Failed to launch new child process
 1:47.48 GECKO(1550) [Child 1558, GMPThread] WARNING: 'NS_FAILED(aResult.result())', file /builds/worker/checkouts/gecko/dom/media/gmp/GMPServiceChild.cpp:123
 1:47.48 GECKO(1550) [Child 1558: GMPThread]: D/GMP GMPServiceChild failed to launch GMP with error: Process has not loaded.
 1:47.48 GECKO(1550) [Child 1558: GMPThread]: D/GMP GMPServiceChild::RemoveShutdownBlockerIfNeeded mPendingGetContentParents=0 mServiceChild->HaveContentParents()=false mShuttingDownOnGMPThread=false

I did some lldb debugging (not that easy with artifact builds) and notice this:
After the failing posix_spawnp $x0 should be the return value and is 2 which is ENOENT which per docs means The new process file does not exist..

Checking the second argument to posix_spawnp gives this (note my custom bundle name):

(lldb) p (char*)$x1
(char *) 0x000000013487c040 "/Users/apehrson/Dev/mozilla-central/obj-aarch64-apple-darwin24.3.0/dist/LocalNightlyDebug.app/Contents/MacOS/media-plugin-helper.app/Contents/MacOS/Firefox Nightly Media Plugin Helper"

But the only binary I have has a different name:

apehrson@apehrson-42665 mozilla-central % ls obj-aarch64-apple-darwin24.3.0/dist/LocalNightlyDebug.app/Contents/MacOS/media-plugin-helper.app/Contents/MacOS/                               
Nightly Media Plugin Helper

Also note

apehrson@apehrson-42665 mozilla-central % grep MOZ_EME_PROCESS ./obj-aarch64-apple-darwin24.3.0/config.status
    'MOZ_EME_PROCESS_BUNDLEID': 'eu.pehrsons.nightly-media-plugin-helper',
    'MOZ_EME_PROCESS_BUNDLENAME': 'media-plugin-helper.app',
    'MOZ_EME_PROCESS_NAME': 'media-plugin-helper',
    'MOZ_EME_PROCESS_NAME_BRANDED': 'Nightly Media Plugin Helper',

I guess there's a disconnect here somewhere, between the artifact binary's official Nightly branding and a local build's unofficial branding.

ac_add_options --with-branding=browser/branding/nightly works around this for now.

Comment 1

[Andreas Pehrson [:pehrsons]]

While this is what happens on macOS, bug 1841944 is the symptom of an artifact build on linux, where a plugin-container based process is used.

Comment 2

[[:sergesanspaille]]

Can you share the output of your mach configure invocation? It looks like the wrong configure.sh is loaded.

Comment 3

[Mike Hommey [:glandium]]

(In reply to [:sergesanspaille] from comment #2)

Can you share the output of your mach configure invocation? It looks like the wrong configure.sh is loaded.

As comment 0 suggests, it's the right configure.sh, but unofficial (local) builds and nightlies have different settings that aren't really compatible because of the branding. What this means to me is that the code part of Firefox shouldn't hardcode branding-related things. Which makes this not a build system problem, but a whatever-is-using-branding-part problem. Here, media or webrtc code.

Comment 4

[Andreas Pehrson [:pehrsons]]

Haik, would you have any thoughts on this?

Comment 5

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

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

Comment 6

[Haik Aftandilian [:haik]]

On Mac, the branding name is used for the GMP child process executable name because it gets displayed in Activity Monitor as the process name (due to sandboxing). We want that to match the Firefox version (Release, Beta, Dev Edition, Nightly) the user has installed so it is clear it is a related process.'

So I understand, for artifact builds we use a XUL built with "Firefox Nightly" channel branding with locally built executables?

For local builds, we could live with the Media Plugin Helper process name not matching the local build branding. We could make it Firefox Nightly instead of Nightly, but I think we want to avoid Firefox branding for local builds.

An alternative could be to make Nightly channel builds fallback to the local build branding name (Nightly) when launching the executable fails.

Or change the branding for the plugin helper process to use "Firefox Nightly" for artifact builds.

I can take this bug.