When running with an artifact build with the latest mozilla-central, I am unable to run xpcshell-tests.

Attempting to run the test shuts down straight away (see attached log).

If as a workaround I do:

MOZ_DISABLE_SOCKET_PROCESS_SANDBOX=1 ./mach xpcshell-test toolkit/components/places/tests/unit/test_annotations.js

then the test runs fine.

This isn't just artifact builds, I've just managed to do a full build and it is broken there as well.

I'm looking into this.

We're crashing in GeckoChildProcessHost::StaticFillMacSandboxInfo() called from SocketProcessHost::StaticFillMacSandboxInfo() due to nsMacUtilsImpl::GetAppPath() failing. GetAppPath() fails because it expects the executable name in argv[0] to have "Contents/MacOS/" in the path but for xpcshell, that is not the case.

In my local tests, argv[0] ends up being ${OBJDIR}/dist/NightlyDebug.app/Contents/Resources/browser/nonexistent-executable which appears to be because CommandLine was not initialized when NS_InitXPCOM() was called.

I think the best thing to do here is a quick fix to allow xpcshell tests to work again by disabling the socket process sandbox for xpcshell tests. We already disable the content sandbox for xpcshell tests so the sandbox setup code has never been used during xpcshell tests.

Once this fix lands, I'll file a follow-up bug to improve the path checking and allow the socket process sandbox to be enabled for these tests.

Sorry, I was on PTO yesterday. Haik, thank you for looking at this in my absense!

I have a similar issue in bug 1621601.
Maybe we should disabling the socket process sandbox for all platforms.

(In reply to Kershaw Chang [:kershaw] from comment #6)

I have a similar issue in bug 1621601.
Maybe we should disabling the socket process sandbox for all platforms.

Thanks. I've r+'d the patch on bug 1621601. Disabling on all platforms is the right choice for now. See also bug 1257098. We can close this bug as a dupe of 1621601 since the fix will address this bug too.