1950664 - Self-build Firefox always crashes on startup when run with `--help` argument in [@ mozilla::ipc::GeckoChildProcessHost::FillMacSandboxInfo]

Status: NEW

(Core :: IPC, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

It doesn't matter if I use an artifact or full build, both variants are crashing when I try to start them with the --help argument specified. I've tried with downloaded builds from Treeherder, and with those it's not reproducible.

Steps:

1. Build Firefox (artifact or full)
2. Run ./mach -- --help and wait for the crash

Crash report: https://crash-stats.mozilla.org/report/index/ac8a39d2-e736-4d0b-8003-939f90250226

MOZ_CRASH Reason:

MOZ_CRASH(Failed to get app path)

Top 10 frames:

0  XUL  MOZ_CrashSequence(void*, long)  mfbt/Assertions.h:272
0  XUL  mozilla::ipc::GeckoChildProcessHost::FillMacSandboxInfo(_MacSandboxInfo&)  ipc/glue/GeckoChildProcessHost.cpp:1807
1  XUL  mozilla::net::SocketProcessHost::FillMacSandboxInfo(_MacSandboxInfo&)  netwerk/ipc/SocketProcessHost.cpp:241
2  XUL  mozilla::ipc::GeckoChildProcessHost::AppendMacSandboxParams(std::__1::vector<...  ipc/glue/GeckoChildProcessHost.cpp:1792
3  XUL  mozilla::ipc::GeckoChildProcessHost::AsyncLaunch(mozilla::geckoargs::ChildPro...  ipc/glue/GeckoChildProcessHost.cpp:722
4  XUL  mozilla::ipc::GeckoChildProcessHost::LaunchAndWaitForProcessHandle(mozilla::g...  ipc/glue/GeckoChildProcessHost.cpp:891
5  XUL  mozilla::net::SocketProcessHost::Launch()  netwerk/ipc/SocketProcessHost.cpp:79
6  XUL  mozilla::net::nsIOService::LaunchSocketProcess()  netwerk/base/nsIOService.cpp:606
7  XUL  mozilla::net::nsHttpHandler::Init()  netwerk/protocol/http/nsHttpHandler.cpp:354
7  XUL  mozilla::net::nsHttpHandler::GetInstance()  netwerk/protocol/http/nsHttpHandler.cpp:200

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

The problem seems to be in nsMacUtilsImpl::GetAppPath at this line:
https://searchfox.org/mozilla-central/source/xpcom/base/nsMacUtilsImpl.cpp#101

The call to RFindInReadable returns false so that we return false in line 121.

Note that this crash goes back beyond the work on bug 381283. Maybe it's related to the aarch64-only build? When downloading any build I will actually get a universal build.

Comment 2

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

This was discussed in IPC bug triage last week and, to try to summarize: --help allows XPCOM components(?) to register additional text to print, which means it needs to load jsm/mjs files, which uses file: URLs, which initializes the HTTP subsystem to generate channel IDs, which launches the socket process, which calls the sandbox code, which tries to get the executable path, except XRE_InitCommandLine hasn't been called yet. There are a few steps in that chain of dependencies which maybe don't need to happen.

Also XRE_InitCommandLine was originally introduced in bug 526397 as a wrapper for CommandLine::Init from the Chromium-derived IPC code, and insofar as CommandLine or anything else from IPC duplicates basic functionality from XPCOM/XRE/MFBT/etc., we generally try to migrate uses of them the not-IPC version where feasible. However, I don't know offhand if this is one of those situations.