gecko-dev/dom/ipc/ContentProcess.cpp

254 строки
7.2 KiB
C++
Исходник Обычный вид История

/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
/* This Source Code Form is subject to the terms of the Mozilla Public
2012-05-21 15:12:37 +04:00
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
#include "mozilla/ipc/IOThreadChild.h"
#include "ContentProcess.h"
Bug 1438678 - Pass early prefs via shared memory instead of the command line. r=bobowen,jld,glandium. This patch replaces the large -intPrefs/-boolPrefs/-stringPrefs flags with a short-lived, anonymous, shared memory segment that is used to pass the early prefs. Removing the bloat from the command line is nice, but more important is the fact that this will let us pass more prefs at content process start-up, which will allow us to remove the early/late prefs split (bug 1436911). Although this mechanism is only used for prefs, it's conceivable that it could be used for other data that must be received very early by children, and for which the command line isn't ideal. Notable details: - Much of the patch deals with the various platform-specific ways of passing handles/fds to children. - Linux and Mac: we use a fixed fd (8) in combination with the new GeckoChildProcessHost::AddFdToRemap() function (which ensures the child won't close the fd). - Android: like Linux and Mac, but the handles get passed via "parcels" and we use the new SetPrefsFd() function instead of the fixed fd. - Windows: there is no need to duplicate the handle because Windows handles are system-wide. But we do use the new GeckoChildProcessHost::AddHandleToShare() function to add it to the list of inheritable handles. We also ensure that list is processed on all paths (MOZ_SANDBOX with sandbox, MOZ_SANDBOX without sandbox, non-MOZ_SANDBOX) so that the handles are marked as inheritable. The handle is passed via the -prefsHandle flag. The -prefsLen flag is used on all platforms to indicate the size of the shared memory segment. - The patch also moves the serialization/deserialization of the prefs in/out of the shared memory into libpref, which is a better spot for it. (This means Preferences::MustSendToContentProcesses() can be removed.) MozReview-Commit-ID: 8fREEBiYFvc --HG-- extra : rebase_source : 7e4c8ebdbcd7d74d6bd2ab3c9e75a6a17dbd8dfe
2018-02-16 09:54:16 +03:00
#include "base/shared_memory.h"
#include "mozilla/Preferences.h"
#include "mozilla/Scheduler.h"
#if defined(XP_MACOSX) && defined(MOZ_CONTENT_SANDBOX)
#include <stdlib.h>
#endif
#if (defined(XP_WIN) || defined(XP_MACOSX)) && defined(MOZ_CONTENT_SANDBOX)
#include "mozilla/SandboxSettings.h"
#include "nsAppDirectoryServiceDefs.h"
#include "nsDirectoryService.h"
#include "nsDirectoryServiceDefs.h"
#endif
using mozilla::ipc::IOThreadChild;
namespace mozilla {
namespace dom {
#if defined(XP_WIN) && defined(MOZ_CONTENT_SANDBOX)
static void
SetTmpEnvironmentVariable(nsIFile* aValue)
{
// Save the TMP environment variable so that is is picked up by GetTempPath().
// Note that we specifically write to the TMP variable, as that is the first
// variable that is checked by GetTempPath() to determine its output.
nsAutoString fullTmpPath;
nsresult rv = aValue->GetPath(fullTmpPath);
if (NS_WARN_IF(NS_FAILED(rv))) {
return;
}
Unused << NS_WARN_IF(!SetEnvironmentVariableW(L"TMP", fullTmpPath.get()));
// We also set TEMP in case there is naughty third-party code that is
// referencing the environment variable directly.
Unused << NS_WARN_IF(!SetEnvironmentVariableW(L"TEMP", fullTmpPath.get()));
}
#endif
#if defined(XP_WIN) && defined(MOZ_CONTENT_SANDBOX)
static void
SetUpSandboxEnvironment()
{
MOZ_ASSERT(nsDirectoryService::gService,
"SetUpSandboxEnvironment relies on nsDirectoryService being initialized");
// On Windows, a sandbox-writable temp directory is used whenever the sandbox
// is enabled.
if (!IsContentSandboxEnabled()) {
return;
}
nsCOMPtr<nsIFile> sandboxedContentTemp;
nsresult rv =
nsDirectoryService::gService->Get(NS_APP_CONTENT_PROCESS_TEMP_DIR,
NS_GET_IID(nsIFile),
getter_AddRefs(sandboxedContentTemp));
if (NS_WARN_IF(NS_FAILED(rv))) {
return;
}
// Change the gecko defined temp directory to our sandbox-writable one.
// Undefine returns a failure if the property is not already set.
Unused << nsDirectoryService::gService->Undefine(NS_OS_TEMP_DIR);
rv = nsDirectoryService::gService->Set(NS_OS_TEMP_DIR, sandboxedContentTemp);
if (NS_WARN_IF(NS_FAILED(rv))) {
return;
}
SetTmpEnvironmentVariable(sandboxedContentTemp);
}
#endif
Bug 1438678 - Pass early prefs via shared memory instead of the command line. r=bobowen,jld,glandium. This patch replaces the large -intPrefs/-boolPrefs/-stringPrefs flags with a short-lived, anonymous, shared memory segment that is used to pass the early prefs. Removing the bloat from the command line is nice, but more important is the fact that this will let us pass more prefs at content process start-up, which will allow us to remove the early/late prefs split (bug 1436911). Although this mechanism is only used for prefs, it's conceivable that it could be used for other data that must be received very early by children, and for which the command line isn't ideal. Notable details: - Much of the patch deals with the various platform-specific ways of passing handles/fds to children. - Linux and Mac: we use a fixed fd (8) in combination with the new GeckoChildProcessHost::AddFdToRemap() function (which ensures the child won't close the fd). - Android: like Linux and Mac, but the handles get passed via "parcels" and we use the new SetPrefsFd() function instead of the fixed fd. - Windows: there is no need to duplicate the handle because Windows handles are system-wide. But we do use the new GeckoChildProcessHost::AddHandleToShare() function to add it to the list of inheritable handles. We also ensure that list is processed on all paths (MOZ_SANDBOX with sandbox, MOZ_SANDBOX without sandbox, non-MOZ_SANDBOX) so that the handles are marked as inheritable. The handle is passed via the -prefsHandle flag. The -prefsLen flag is used on all platforms to indicate the size of the shared memory segment. - The patch also moves the serialization/deserialization of the prefs in/out of the shared memory into libpref, which is a better spot for it. (This means Preferences::MustSendToContentProcesses() can be removed.) MozReview-Commit-ID: 8fREEBiYFvc --HG-- extra : rebase_source : 7e4c8ebdbcd7d74d6bd2ab3c9e75a6a17dbd8dfe
2018-02-16 09:54:16 +03:00
#ifdef ANDROID
static int gPrefsFd = -1;
void
SetPrefsFd(int aFd)
{
gPrefsFd = aFd;
}
#endif
bool
ContentProcess::Init(int aArgc, char* aArgv[])
{
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm The current code is a bit of a mess. This patch does the following. - Changes the processing from backwards to forwards. This avoids the need for all the `found` booleans, because if a flag is present multiple times, the last one will naturally override. - Tightens up the checking. It now doesn't use assertions, but instead returns false if any of the options are missing arguments, or have malformed arguments, or any of the mandatory flags are missing. (It assumes that -appdir and -profile are optional.) - Renames the loop variable `idx` as `i`. - Changes `!strcmp(...)` to `strcmp(...) == 0`, because I find that clearer. - Avoids a redundant nsCString when handling -appdir. The patch also tweaks GeckoChildProcessHost::mGroupId, which was buggy. It holds the appModelUserId argument, which XRE_InitChildProcess() always expects is present in the command. But it's only set to a non-empty value in InitWindowsGroupID(), which is only called for plugin processes. So in lots of cases the appModelUserId argument was missing, and a different argument would be interpreted as the appModelUserId argument (seemingly without noticeable ill effect). The patch changes things to mGroupId defaults to "-", which means it's always present in the command. Note: all this explains why the old code for ContentProcess::Init() started processing from argument aArgc, instead of aArgc-1 as you might expect -- it had to read one extra arg in order to see the argument following -appdir, because XRE_InitChildProcess() was decrementing aArgc for the appModelUserId argument even when that argument wasn't present. The new code for ContentProcess::Init() doesn't have to read past aArgc-1 because the mGroupId fix ensures the appModelUserId argument is always present. MozReview-Commit-ID: 8a8k6ABYMgo --HG-- extra : rebase_source : 70695125ee26e67af3337119f4dfc293a0dab74c
2018-03-16 04:23:10 +03:00
Maybe<uint64_t> childID;
Maybe<bool> isForBrowser;
Maybe<base::SharedMemoryHandle> prefsHandle;
Maybe<size_t> prefsLen;
Maybe<const char*> schedulerPrefs;
Maybe<const char*> parentBuildID;
#if defined(XP_MACOSX) && defined(MOZ_CONTENT_SANDBOX)
nsCOMPtr<nsIFile> profileDir;
#endif
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm The current code is a bit of a mess. This patch does the following. - Changes the processing from backwards to forwards. This avoids the need for all the `found` booleans, because if a flag is present multiple times, the last one will naturally override. - Tightens up the checking. It now doesn't use assertions, but instead returns false if any of the options are missing arguments, or have malformed arguments, or any of the mandatory flags are missing. (It assumes that -appdir and -profile are optional.) - Renames the loop variable `idx` as `i`. - Changes `!strcmp(...)` to `strcmp(...) == 0`, because I find that clearer. - Avoids a redundant nsCString when handling -appdir. The patch also tweaks GeckoChildProcessHost::mGroupId, which was buggy. It holds the appModelUserId argument, which XRE_InitChildProcess() always expects is present in the command. But it's only set to a non-empty value in InitWindowsGroupID(), which is only called for plugin processes. So in lots of cases the appModelUserId argument was missing, and a different argument would be interpreted as the appModelUserId argument (seemingly without noticeable ill effect). The patch changes things to mGroupId defaults to "-", which means it's always present in the command. Note: all this explains why the old code for ContentProcess::Init() started processing from argument aArgc, instead of aArgc-1 as you might expect -- it had to read one extra arg in order to see the argument following -appdir, because XRE_InitChildProcess() was decrementing aArgc for the appModelUserId argument even when that argument wasn't present. The new code for ContentProcess::Init() doesn't have to read past aArgc-1 because the mGroupId fix ensures the appModelUserId argument is always present. MozReview-Commit-ID: 8a8k6ABYMgo --HG-- extra : rebase_source : 70695125ee26e67af3337119f4dfc293a0dab74c
2018-03-16 04:23:10 +03:00
for (int i = 1; i < aArgc; i++) {
if (!aArgv[i]) {
continue;
}
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm The current code is a bit of a mess. This patch does the following. - Changes the processing from backwards to forwards. This avoids the need for all the `found` booleans, because if a flag is present multiple times, the last one will naturally override. - Tightens up the checking. It now doesn't use assertions, but instead returns false if any of the options are missing arguments, or have malformed arguments, or any of the mandatory flags are missing. (It assumes that -appdir and -profile are optional.) - Renames the loop variable `idx` as `i`. - Changes `!strcmp(...)` to `strcmp(...) == 0`, because I find that clearer. - Avoids a redundant nsCString when handling -appdir. The patch also tweaks GeckoChildProcessHost::mGroupId, which was buggy. It holds the appModelUserId argument, which XRE_InitChildProcess() always expects is present in the command. But it's only set to a non-empty value in InitWindowsGroupID(), which is only called for plugin processes. So in lots of cases the appModelUserId argument was missing, and a different argument would be interpreted as the appModelUserId argument (seemingly without noticeable ill effect). The patch changes things to mGroupId defaults to "-", which means it's always present in the command. Note: all this explains why the old code for ContentProcess::Init() started processing from argument aArgc, instead of aArgc-1 as you might expect -- it had to read one extra arg in order to see the argument following -appdir, because XRE_InitChildProcess() was decrementing aArgc for the appModelUserId argument even when that argument wasn't present. The new code for ContentProcess::Init() doesn't have to read past aArgc-1 because the mGroupId fix ensures the appModelUserId argument is always present. MozReview-Commit-ID: 8a8k6ABYMgo --HG-- extra : rebase_source : 70695125ee26e67af3337119f4dfc293a0dab74c
2018-03-16 04:23:10 +03:00
if (strcmp(aArgv[i], "-appdir") == 0) {
if (++i == aArgc) {
return false;
}
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm The current code is a bit of a mess. This patch does the following. - Changes the processing from backwards to forwards. This avoids the need for all the `found` booleans, because if a flag is present multiple times, the last one will naturally override. - Tightens up the checking. It now doesn't use assertions, but instead returns false if any of the options are missing arguments, or have malformed arguments, or any of the mandatory flags are missing. (It assumes that -appdir and -profile are optional.) - Renames the loop variable `idx` as `i`. - Changes `!strcmp(...)` to `strcmp(...) == 0`, because I find that clearer. - Avoids a redundant nsCString when handling -appdir. The patch also tweaks GeckoChildProcessHost::mGroupId, which was buggy. It holds the appModelUserId argument, which XRE_InitChildProcess() always expects is present in the command. But it's only set to a non-empty value in InitWindowsGroupID(), which is only called for plugin processes. So in lots of cases the appModelUserId argument was missing, and a different argument would be interpreted as the appModelUserId argument (seemingly without noticeable ill effect). The patch changes things to mGroupId defaults to "-", which means it's always present in the command. Note: all this explains why the old code for ContentProcess::Init() started processing from argument aArgc, instead of aArgc-1 as you might expect -- it had to read one extra arg in order to see the argument following -appdir, because XRE_InitChildProcess() was decrementing aArgc for the appModelUserId argument even when that argument wasn't present. The new code for ContentProcess::Init() doesn't have to read past aArgc-1 because the mGroupId fix ensures the appModelUserId argument is always present. MozReview-Commit-ID: 8a8k6ABYMgo --HG-- extra : rebase_source : 70695125ee26e67af3337119f4dfc293a0dab74c
2018-03-16 04:23:10 +03:00
nsDependentCString appDir(aArgv[i]);
mXREEmbed.SetAppDir(appDir);
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm The current code is a bit of a mess. This patch does the following. - Changes the processing from backwards to forwards. This avoids the need for all the `found` booleans, because if a flag is present multiple times, the last one will naturally override. - Tightens up the checking. It now doesn't use assertions, but instead returns false if any of the options are missing arguments, or have malformed arguments, or any of the mandatory flags are missing. (It assumes that -appdir and -profile are optional.) - Renames the loop variable `idx` as `i`. - Changes `!strcmp(...)` to `strcmp(...) == 0`, because I find that clearer. - Avoids a redundant nsCString when handling -appdir. The patch also tweaks GeckoChildProcessHost::mGroupId, which was buggy. It holds the appModelUserId argument, which XRE_InitChildProcess() always expects is present in the command. But it's only set to a non-empty value in InitWindowsGroupID(), which is only called for plugin processes. So in lots of cases the appModelUserId argument was missing, and a different argument would be interpreted as the appModelUserId argument (seemingly without noticeable ill effect). The patch changes things to mGroupId defaults to "-", which means it's always present in the command. Note: all this explains why the old code for ContentProcess::Init() started processing from argument aArgc, instead of aArgc-1 as you might expect -- it had to read one extra arg in order to see the argument following -appdir, because XRE_InitChildProcess() was decrementing aArgc for the appModelUserId argument even when that argument wasn't present. The new code for ContentProcess::Init() doesn't have to read past aArgc-1 because the mGroupId fix ensures the appModelUserId argument is always present. MozReview-Commit-ID: 8a8k6ABYMgo --HG-- extra : rebase_source : 70695125ee26e67af3337119f4dfc293a0dab74c
2018-03-16 04:23:10 +03:00
} else if (strcmp(aArgv[i], "-childID") == 0) {
if (++i == aArgc) {
return false;
}
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm The current code is a bit of a mess. This patch does the following. - Changes the processing from backwards to forwards. This avoids the need for all the `found` booleans, because if a flag is present multiple times, the last one will naturally override. - Tightens up the checking. It now doesn't use assertions, but instead returns false if any of the options are missing arguments, or have malformed arguments, or any of the mandatory flags are missing. (It assumes that -appdir and -profile are optional.) - Renames the loop variable `idx` as `i`. - Changes `!strcmp(...)` to `strcmp(...) == 0`, because I find that clearer. - Avoids a redundant nsCString when handling -appdir. The patch also tweaks GeckoChildProcessHost::mGroupId, which was buggy. It holds the appModelUserId argument, which XRE_InitChildProcess() always expects is present in the command. But it's only set to a non-empty value in InitWindowsGroupID(), which is only called for plugin processes. So in lots of cases the appModelUserId argument was missing, and a different argument would be interpreted as the appModelUserId argument (seemingly without noticeable ill effect). The patch changes things to mGroupId defaults to "-", which means it's always present in the command. Note: all this explains why the old code for ContentProcess::Init() started processing from argument aArgc, instead of aArgc-1 as you might expect -- it had to read one extra arg in order to see the argument following -appdir, because XRE_InitChildProcess() was decrementing aArgc for the appModelUserId argument even when that argument wasn't present. The new code for ContentProcess::Init() doesn't have to read past aArgc-1 because the mGroupId fix ensures the appModelUserId argument is always present. MozReview-Commit-ID: 8a8k6ABYMgo --HG-- extra : rebase_source : 70695125ee26e67af3337119f4dfc293a0dab74c
2018-03-16 04:23:10 +03:00
char* str = aArgv[i];
childID = Some(strtoull(str, &str, 10));
if (str[0] != '\0') {
return false;
}
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm The current code is a bit of a mess. This patch does the following. - Changes the processing from backwards to forwards. This avoids the need for all the `found` booleans, because if a flag is present multiple times, the last one will naturally override. - Tightens up the checking. It now doesn't use assertions, but instead returns false if any of the options are missing arguments, or have malformed arguments, or any of the mandatory flags are missing. (It assumes that -appdir and -profile are optional.) - Renames the loop variable `idx` as `i`. - Changes `!strcmp(...)` to `strcmp(...) == 0`, because I find that clearer. - Avoids a redundant nsCString when handling -appdir. The patch also tweaks GeckoChildProcessHost::mGroupId, which was buggy. It holds the appModelUserId argument, which XRE_InitChildProcess() always expects is present in the command. But it's only set to a non-empty value in InitWindowsGroupID(), which is only called for plugin processes. So in lots of cases the appModelUserId argument was missing, and a different argument would be interpreted as the appModelUserId argument (seemingly without noticeable ill effect). The patch changes things to mGroupId defaults to "-", which means it's always present in the command. Note: all this explains why the old code for ContentProcess::Init() started processing from argument aArgc, instead of aArgc-1 as you might expect -- it had to read one extra arg in order to see the argument following -appdir, because XRE_InitChildProcess() was decrementing aArgc for the appModelUserId argument even when that argument wasn't present. The new code for ContentProcess::Init() doesn't have to read past aArgc-1 because the mGroupId fix ensures the appModelUserId argument is always present. MozReview-Commit-ID: 8a8k6ABYMgo --HG-- extra : rebase_source : 70695125ee26e67af3337119f4dfc293a0dab74c
2018-03-16 04:23:10 +03:00
} else if (strcmp(aArgv[i], "-isForBrowser") == 0) {
isForBrowser = Some(true);
} else if (strcmp(aArgv[i], "-notForBrowser") == 0) {
isForBrowser = Some(false);
Bug 1438678 - Pass early prefs via shared memory instead of the command line. r=bobowen,jld,glandium. This patch replaces the large -intPrefs/-boolPrefs/-stringPrefs flags with a short-lived, anonymous, shared memory segment that is used to pass the early prefs. Removing the bloat from the command line is nice, but more important is the fact that this will let us pass more prefs at content process start-up, which will allow us to remove the early/late prefs split (bug 1436911). Although this mechanism is only used for prefs, it's conceivable that it could be used for other data that must be received very early by children, and for which the command line isn't ideal. Notable details: - Much of the patch deals with the various platform-specific ways of passing handles/fds to children. - Linux and Mac: we use a fixed fd (8) in combination with the new GeckoChildProcessHost::AddFdToRemap() function (which ensures the child won't close the fd). - Android: like Linux and Mac, but the handles get passed via "parcels" and we use the new SetPrefsFd() function instead of the fixed fd. - Windows: there is no need to duplicate the handle because Windows handles are system-wide. But we do use the new GeckoChildProcessHost::AddHandleToShare() function to add it to the list of inheritable handles. We also ensure that list is processed on all paths (MOZ_SANDBOX with sandbox, MOZ_SANDBOX without sandbox, non-MOZ_SANDBOX) so that the handles are marked as inheritable. The handle is passed via the -prefsHandle flag. The -prefsLen flag is used on all platforms to indicate the size of the shared memory segment. - The patch also moves the serialization/deserialization of the prefs in/out of the shared memory into libpref, which is a better spot for it. (This means Preferences::MustSendToContentProcesses() can be removed.) MozReview-Commit-ID: 8fREEBiYFvc --HG-- extra : rebase_source : 7e4c8ebdbcd7d74d6bd2ab3c9e75a6a17dbd8dfe
2018-02-16 09:54:16 +03:00
#ifdef XP_WIN
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm The current code is a bit of a mess. This patch does the following. - Changes the processing from backwards to forwards. This avoids the need for all the `found` booleans, because if a flag is present multiple times, the last one will naturally override. - Tightens up the checking. It now doesn't use assertions, but instead returns false if any of the options are missing arguments, or have malformed arguments, or any of the mandatory flags are missing. (It assumes that -appdir and -profile are optional.) - Renames the loop variable `idx` as `i`. - Changes `!strcmp(...)` to `strcmp(...) == 0`, because I find that clearer. - Avoids a redundant nsCString when handling -appdir. The patch also tweaks GeckoChildProcessHost::mGroupId, which was buggy. It holds the appModelUserId argument, which XRE_InitChildProcess() always expects is present in the command. But it's only set to a non-empty value in InitWindowsGroupID(), which is only called for plugin processes. So in lots of cases the appModelUserId argument was missing, and a different argument would be interpreted as the appModelUserId argument (seemingly without noticeable ill effect). The patch changes things to mGroupId defaults to "-", which means it's always present in the command. Note: all this explains why the old code for ContentProcess::Init() started processing from argument aArgc, instead of aArgc-1 as you might expect -- it had to read one extra arg in order to see the argument following -appdir, because XRE_InitChildProcess() was decrementing aArgc for the appModelUserId argument even when that argument wasn't present. The new code for ContentProcess::Init() doesn't have to read past aArgc-1 because the mGroupId fix ensures the appModelUserId argument is always present. MozReview-Commit-ID: 8a8k6ABYMgo --HG-- extra : rebase_source : 70695125ee26e67af3337119f4dfc293a0dab74c
2018-03-16 04:23:10 +03:00
} else if (strcmp(aArgv[i], "-prefsHandle") == 0) {
if (++i == aArgc) {
return false;
}
// ContentParent uses %zu to print a word-sized unsigned integer. So
// even though strtoull() returns a long long int, it will fit in a
// uintptr_t.
char* str = aArgv[i];
prefsHandle = Some(reinterpret_cast<HANDLE>(strtoull(str, &str, 10)));
if (str[0] != '\0') {
return false;
}
Bug 1438678 - Pass early prefs via shared memory instead of the command line. r=bobowen,jld,glandium. This patch replaces the large -intPrefs/-boolPrefs/-stringPrefs flags with a short-lived, anonymous, shared memory segment that is used to pass the early prefs. Removing the bloat from the command line is nice, but more important is the fact that this will let us pass more prefs at content process start-up, which will allow us to remove the early/late prefs split (bug 1436911). Although this mechanism is only used for prefs, it's conceivable that it could be used for other data that must be received very early by children, and for which the command line isn't ideal. Notable details: - Much of the patch deals with the various platform-specific ways of passing handles/fds to children. - Linux and Mac: we use a fixed fd (8) in combination with the new GeckoChildProcessHost::AddFdToRemap() function (which ensures the child won't close the fd). - Android: like Linux and Mac, but the handles get passed via "parcels" and we use the new SetPrefsFd() function instead of the fixed fd. - Windows: there is no need to duplicate the handle because Windows handles are system-wide. But we do use the new GeckoChildProcessHost::AddHandleToShare() function to add it to the list of inheritable handles. We also ensure that list is processed on all paths (MOZ_SANDBOX with sandbox, MOZ_SANDBOX without sandbox, non-MOZ_SANDBOX) so that the handles are marked as inheritable. The handle is passed via the -prefsHandle flag. The -prefsLen flag is used on all platforms to indicate the size of the shared memory segment. - The patch also moves the serialization/deserialization of the prefs in/out of the shared memory into libpref, which is a better spot for it. (This means Preferences::MustSendToContentProcesses() can be removed.) MozReview-Commit-ID: 8fREEBiYFvc --HG-- extra : rebase_source : 7e4c8ebdbcd7d74d6bd2ab3c9e75a6a17dbd8dfe
2018-02-16 09:54:16 +03:00
#endif
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm The current code is a bit of a mess. This patch does the following. - Changes the processing from backwards to forwards. This avoids the need for all the `found` booleans, because if a flag is present multiple times, the last one will naturally override. - Tightens up the checking. It now doesn't use assertions, but instead returns false if any of the options are missing arguments, or have malformed arguments, or any of the mandatory flags are missing. (It assumes that -appdir and -profile are optional.) - Renames the loop variable `idx` as `i`. - Changes `!strcmp(...)` to `strcmp(...) == 0`, because I find that clearer. - Avoids a redundant nsCString when handling -appdir. The patch also tweaks GeckoChildProcessHost::mGroupId, which was buggy. It holds the appModelUserId argument, which XRE_InitChildProcess() always expects is present in the command. But it's only set to a non-empty value in InitWindowsGroupID(), which is only called for plugin processes. So in lots of cases the appModelUserId argument was missing, and a different argument would be interpreted as the appModelUserId argument (seemingly without noticeable ill effect). The patch changes things to mGroupId defaults to "-", which means it's always present in the command. Note: all this explains why the old code for ContentProcess::Init() started processing from argument aArgc, instead of aArgc-1 as you might expect -- it had to read one extra arg in order to see the argument following -appdir, because XRE_InitChildProcess() was decrementing aArgc for the appModelUserId argument even when that argument wasn't present. The new code for ContentProcess::Init() doesn't have to read past aArgc-1 because the mGroupId fix ensures the appModelUserId argument is always present. MozReview-Commit-ID: 8a8k6ABYMgo --HG-- extra : rebase_source : 70695125ee26e67af3337119f4dfc293a0dab74c
2018-03-16 04:23:10 +03:00
} else if (strcmp(aArgv[i], "-prefsLen") == 0) {
if (++i == aArgc) {
return false;
}
// ContentParent uses %zu to print a word-sized unsigned integer. So
// even though strtoull() returns a long long int, it will fit in a
// uintptr_t.
char* str = aArgv[i];
prefsLen = Some(strtoull(str, &str, 10));
if (str[0] != '\0') {
return false;
}
} else if (strcmp(aArgv[i], "-schedulerPrefs") == 0) {
if (++i == aArgc) {
return false;
}
schedulerPrefs = Some(aArgv[i]);
} else if (strcmp(aArgv[i], "-safeMode") == 0) {
gSafeMode = true;
} else if (strcmp(aArgv[i], "-parentBuildID") == 0) {
if (++i == aArgc) {
return false;
}
parentBuildID = Some(aArgv[i]);
#if defined(XP_MACOSX) && defined(MOZ_CONTENT_SANDBOX)
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm The current code is a bit of a mess. This patch does the following. - Changes the processing from backwards to forwards. This avoids the need for all the `found` booleans, because if a flag is present multiple times, the last one will naturally override. - Tightens up the checking. It now doesn't use assertions, but instead returns false if any of the options are missing arguments, or have malformed arguments, or any of the mandatory flags are missing. (It assumes that -appdir and -profile are optional.) - Renames the loop variable `idx` as `i`. - Changes `!strcmp(...)` to `strcmp(...) == 0`, because I find that clearer. - Avoids a redundant nsCString when handling -appdir. The patch also tweaks GeckoChildProcessHost::mGroupId, which was buggy. It holds the appModelUserId argument, which XRE_InitChildProcess() always expects is present in the command. But it's only set to a non-empty value in InitWindowsGroupID(), which is only called for plugin processes. So in lots of cases the appModelUserId argument was missing, and a different argument would be interpreted as the appModelUserId argument (seemingly without noticeable ill effect). The patch changes things to mGroupId defaults to "-", which means it's always present in the command. Note: all this explains why the old code for ContentProcess::Init() started processing from argument aArgc, instead of aArgc-1 as you might expect -- it had to read one extra arg in order to see the argument following -appdir, because XRE_InitChildProcess() was decrementing aArgc for the appModelUserId argument even when that argument wasn't present. The new code for ContentProcess::Init() doesn't have to read past aArgc-1 because the mGroupId fix ensures the appModelUserId argument is always present. MozReview-Commit-ID: 8a8k6ABYMgo --HG-- extra : rebase_source : 70695125ee26e67af3337119f4dfc293a0dab74c
2018-03-16 04:23:10 +03:00
} else if (strcmp(aArgv[i], "-profile") == 0) {
if (++i == aArgc) {
return false;
}
bool flag;
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm The current code is a bit of a mess. This patch does the following. - Changes the processing from backwards to forwards. This avoids the need for all the `found` booleans, because if a flag is present multiple times, the last one will naturally override. - Tightens up the checking. It now doesn't use assertions, but instead returns false if any of the options are missing arguments, or have malformed arguments, or any of the mandatory flags are missing. (It assumes that -appdir and -profile are optional.) - Renames the loop variable `idx` as `i`. - Changes `!strcmp(...)` to `strcmp(...) == 0`, because I find that clearer. - Avoids a redundant nsCString when handling -appdir. The patch also tweaks GeckoChildProcessHost::mGroupId, which was buggy. It holds the appModelUserId argument, which XRE_InitChildProcess() always expects is present in the command. But it's only set to a non-empty value in InitWindowsGroupID(), which is only called for plugin processes. So in lots of cases the appModelUserId argument was missing, and a different argument would be interpreted as the appModelUserId argument (seemingly without noticeable ill effect). The patch changes things to mGroupId defaults to "-", which means it's always present in the command. Note: all this explains why the old code for ContentProcess::Init() started processing from argument aArgc, instead of aArgc-1 as you might expect -- it had to read one extra arg in order to see the argument following -appdir, because XRE_InitChildProcess() was decrementing aArgc for the appModelUserId argument even when that argument wasn't present. The new code for ContentProcess::Init() doesn't have to read past aArgc-1 because the mGroupId fix ensures the appModelUserId argument is always present. MozReview-Commit-ID: 8a8k6ABYMgo --HG-- extra : rebase_source : 70695125ee26e67af3337119f4dfc293a0dab74c
2018-03-16 04:23:10 +03:00
nsresult rv = XRE_GetFileFromPath(aArgv[i], getter_AddRefs(profileDir));
if (NS_FAILED(rv) || NS_FAILED(profileDir->Exists(&flag)) || !flag) {
NS_WARNING("Invalid profile directory passed to content process.");
profileDir = nullptr;
}
#endif /* XP_MACOSX && MOZ_CONTENT_SANDBOX */
}
}
Bug 1438678 - Pass early prefs via shared memory instead of the command line. r=bobowen,jld,glandium. This patch replaces the large -intPrefs/-boolPrefs/-stringPrefs flags with a short-lived, anonymous, shared memory segment that is used to pass the early prefs. Removing the bloat from the command line is nice, but more important is the fact that this will let us pass more prefs at content process start-up, which will allow us to remove the early/late prefs split (bug 1436911). Although this mechanism is only used for prefs, it's conceivable that it could be used for other data that must be received very early by children, and for which the command line isn't ideal. Notable details: - Much of the patch deals with the various platform-specific ways of passing handles/fds to children. - Linux and Mac: we use a fixed fd (8) in combination with the new GeckoChildProcessHost::AddFdToRemap() function (which ensures the child won't close the fd). - Android: like Linux and Mac, but the handles get passed via "parcels" and we use the new SetPrefsFd() function instead of the fixed fd. - Windows: there is no need to duplicate the handle because Windows handles are system-wide. But we do use the new GeckoChildProcessHost::AddHandleToShare() function to add it to the list of inheritable handles. We also ensure that list is processed on all paths (MOZ_SANDBOX with sandbox, MOZ_SANDBOX without sandbox, non-MOZ_SANDBOX) so that the handles are marked as inheritable. The handle is passed via the -prefsHandle flag. The -prefsLen flag is used on all platforms to indicate the size of the shared memory segment. - The patch also moves the serialization/deserialization of the prefs in/out of the shared memory into libpref, which is a better spot for it. (This means Preferences::MustSendToContentProcesses() can be removed.) MozReview-Commit-ID: 8fREEBiYFvc --HG-- extra : rebase_source : 7e4c8ebdbcd7d74d6bd2ab3c9e75a6a17dbd8dfe
2018-02-16 09:54:16 +03:00
#ifdef ANDROID
// Android is different; get the FD via gPrefsFd instead of a fixed fd.
MOZ_RELEASE_ASSERT(gPrefsFd != -1);
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm The current code is a bit of a mess. This patch does the following. - Changes the processing from backwards to forwards. This avoids the need for all the `found` booleans, because if a flag is present multiple times, the last one will naturally override. - Tightens up the checking. It now doesn't use assertions, but instead returns false if any of the options are missing arguments, or have malformed arguments, or any of the mandatory flags are missing. (It assumes that -appdir and -profile are optional.) - Renames the loop variable `idx` as `i`. - Changes `!strcmp(...)` to `strcmp(...) == 0`, because I find that clearer. - Avoids a redundant nsCString when handling -appdir. The patch also tweaks GeckoChildProcessHost::mGroupId, which was buggy. It holds the appModelUserId argument, which XRE_InitChildProcess() always expects is present in the command. But it's only set to a non-empty value in InitWindowsGroupID(), which is only called for plugin processes. So in lots of cases the appModelUserId argument was missing, and a different argument would be interpreted as the appModelUserId argument (seemingly without noticeable ill effect). The patch changes things to mGroupId defaults to "-", which means it's always present in the command. Note: all this explains why the old code for ContentProcess::Init() started processing from argument aArgc, instead of aArgc-1 as you might expect -- it had to read one extra arg in order to see the argument following -appdir, because XRE_InitChildProcess() was decrementing aArgc for the appModelUserId argument even when that argument wasn't present. The new code for ContentProcess::Init() doesn't have to read past aArgc-1 because the mGroupId fix ensures the appModelUserId argument is always present. MozReview-Commit-ID: 8a8k6ABYMgo --HG-- extra : rebase_source : 70695125ee26e67af3337119f4dfc293a0dab74c
2018-03-16 04:23:10 +03:00
prefsHandle = Some(base::FileDescriptor(gPrefsFd, /* auto_close */ true));
Bug 1438678 - Pass early prefs via shared memory instead of the command line. r=bobowen,jld,glandium. This patch replaces the large -intPrefs/-boolPrefs/-stringPrefs flags with a short-lived, anonymous, shared memory segment that is used to pass the early prefs. Removing the bloat from the command line is nice, but more important is the fact that this will let us pass more prefs at content process start-up, which will allow us to remove the early/late prefs split (bug 1436911). Although this mechanism is only used for prefs, it's conceivable that it could be used for other data that must be received very early by children, and for which the command line isn't ideal. Notable details: - Much of the patch deals with the various platform-specific ways of passing handles/fds to children. - Linux and Mac: we use a fixed fd (8) in combination with the new GeckoChildProcessHost::AddFdToRemap() function (which ensures the child won't close the fd). - Android: like Linux and Mac, but the handles get passed via "parcels" and we use the new SetPrefsFd() function instead of the fixed fd. - Windows: there is no need to duplicate the handle because Windows handles are system-wide. But we do use the new GeckoChildProcessHost::AddHandleToShare() function to add it to the list of inheritable handles. We also ensure that list is processed on all paths (MOZ_SANDBOX with sandbox, MOZ_SANDBOX without sandbox, non-MOZ_SANDBOX) so that the handles are marked as inheritable. The handle is passed via the -prefsHandle flag. The -prefsLen flag is used on all platforms to indicate the size of the shared memory segment. - The patch also moves the serialization/deserialization of the prefs in/out of the shared memory into libpref, which is a better spot for it. (This means Preferences::MustSendToContentProcesses() can be removed.) MozReview-Commit-ID: 8fREEBiYFvc --HG-- extra : rebase_source : 7e4c8ebdbcd7d74d6bd2ab3c9e75a6a17dbd8dfe
2018-02-16 09:54:16 +03:00
#elif XP_UNIX
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm The current code is a bit of a mess. This patch does the following. - Changes the processing from backwards to forwards. This avoids the need for all the `found` booleans, because if a flag is present multiple times, the last one will naturally override. - Tightens up the checking. It now doesn't use assertions, but instead returns false if any of the options are missing arguments, or have malformed arguments, or any of the mandatory flags are missing. (It assumes that -appdir and -profile are optional.) - Renames the loop variable `idx` as `i`. - Changes `!strcmp(...)` to `strcmp(...) == 0`, because I find that clearer. - Avoids a redundant nsCString when handling -appdir. The patch also tweaks GeckoChildProcessHost::mGroupId, which was buggy. It holds the appModelUserId argument, which XRE_InitChildProcess() always expects is present in the command. But it's only set to a non-empty value in InitWindowsGroupID(), which is only called for plugin processes. So in lots of cases the appModelUserId argument was missing, and a different argument would be interpreted as the appModelUserId argument (seemingly without noticeable ill effect). The patch changes things to mGroupId defaults to "-", which means it's always present in the command. Note: all this explains why the old code for ContentProcess::Init() started processing from argument aArgc, instead of aArgc-1 as you might expect -- it had to read one extra arg in order to see the argument following -appdir, because XRE_InitChildProcess() was decrementing aArgc for the appModelUserId argument even when that argument wasn't present. The new code for ContentProcess::Init() doesn't have to read past aArgc-1 because the mGroupId fix ensures the appModelUserId argument is always present. MozReview-Commit-ID: 8a8k6ABYMgo --HG-- extra : rebase_source : 70695125ee26e67af3337119f4dfc293a0dab74c
2018-03-16 04:23:10 +03:00
prefsHandle = Some(base::FileDescriptor(kPrefsFileDescriptor,
/* auto_close */ true));
Bug 1438678 - Pass early prefs via shared memory instead of the command line. r=bobowen,jld,glandium. This patch replaces the large -intPrefs/-boolPrefs/-stringPrefs flags with a short-lived, anonymous, shared memory segment that is used to pass the early prefs. Removing the bloat from the command line is nice, but more important is the fact that this will let us pass more prefs at content process start-up, which will allow us to remove the early/late prefs split (bug 1436911). Although this mechanism is only used for prefs, it's conceivable that it could be used for other data that must be received very early by children, and for which the command line isn't ideal. Notable details: - Much of the patch deals with the various platform-specific ways of passing handles/fds to children. - Linux and Mac: we use a fixed fd (8) in combination with the new GeckoChildProcessHost::AddFdToRemap() function (which ensures the child won't close the fd). - Android: like Linux and Mac, but the handles get passed via "parcels" and we use the new SetPrefsFd() function instead of the fixed fd. - Windows: there is no need to duplicate the handle because Windows handles are system-wide. But we do use the new GeckoChildProcessHost::AddHandleToShare() function to add it to the list of inheritable handles. We also ensure that list is processed on all paths (MOZ_SANDBOX with sandbox, MOZ_SANDBOX without sandbox, non-MOZ_SANDBOX) so that the handles are marked as inheritable. The handle is passed via the -prefsHandle flag. The -prefsLen flag is used on all platforms to indicate the size of the shared memory segment. - The patch also moves the serialization/deserialization of the prefs in/out of the shared memory into libpref, which is a better spot for it. (This means Preferences::MustSendToContentProcesses() can be removed.) MozReview-Commit-ID: 8fREEBiYFvc --HG-- extra : rebase_source : 7e4c8ebdbcd7d74d6bd2ab3c9e75a6a17dbd8dfe
2018-02-16 09:54:16 +03:00
#endif
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm The current code is a bit of a mess. This patch does the following. - Changes the processing from backwards to forwards. This avoids the need for all the `found` booleans, because if a flag is present multiple times, the last one will naturally override. - Tightens up the checking. It now doesn't use assertions, but instead returns false if any of the options are missing arguments, or have malformed arguments, or any of the mandatory flags are missing. (It assumes that -appdir and -profile are optional.) - Renames the loop variable `idx` as `i`. - Changes `!strcmp(...)` to `strcmp(...) == 0`, because I find that clearer. - Avoids a redundant nsCString when handling -appdir. The patch also tweaks GeckoChildProcessHost::mGroupId, which was buggy. It holds the appModelUserId argument, which XRE_InitChildProcess() always expects is present in the command. But it's only set to a non-empty value in InitWindowsGroupID(), which is only called for plugin processes. So in lots of cases the appModelUserId argument was missing, and a different argument would be interpreted as the appModelUserId argument (seemingly without noticeable ill effect). The patch changes things to mGroupId defaults to "-", which means it's always present in the command. Note: all this explains why the old code for ContentProcess::Init() started processing from argument aArgc, instead of aArgc-1 as you might expect -- it had to read one extra arg in order to see the argument following -appdir, because XRE_InitChildProcess() was decrementing aArgc for the appModelUserId argument even when that argument wasn't present. The new code for ContentProcess::Init() doesn't have to read past aArgc-1 because the mGroupId fix ensures the appModelUserId argument is always present. MozReview-Commit-ID: 8a8k6ABYMgo --HG-- extra : rebase_source : 70695125ee26e67af3337119f4dfc293a0dab74c
2018-03-16 04:23:10 +03:00
// Did we find all the mandatory flags?
if (childID.isNothing() ||
isForBrowser.isNothing() ||
prefsHandle.isNothing() ||
prefsLen.isNothing() ||
schedulerPrefs.isNothing() ||
parentBuildID.isNothing()) {
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm The current code is a bit of a mess. This patch does the following. - Changes the processing from backwards to forwards. This avoids the need for all the `found` booleans, because if a flag is present multiple times, the last one will naturally override. - Tightens up the checking. It now doesn't use assertions, but instead returns false if any of the options are missing arguments, or have malformed arguments, or any of the mandatory flags are missing. (It assumes that -appdir and -profile are optional.) - Renames the loop variable `idx` as `i`. - Changes `!strcmp(...)` to `strcmp(...) == 0`, because I find that clearer. - Avoids a redundant nsCString when handling -appdir. The patch also tweaks GeckoChildProcessHost::mGroupId, which was buggy. It holds the appModelUserId argument, which XRE_InitChildProcess() always expects is present in the command. But it's only set to a non-empty value in InitWindowsGroupID(), which is only called for plugin processes. So in lots of cases the appModelUserId argument was missing, and a different argument would be interpreted as the appModelUserId argument (seemingly without noticeable ill effect). The patch changes things to mGroupId defaults to "-", which means it's always present in the command. Note: all this explains why the old code for ContentProcess::Init() started processing from argument aArgc, instead of aArgc-1 as you might expect -- it had to read one extra arg in order to see the argument following -appdir, because XRE_InitChildProcess() was decrementing aArgc for the appModelUserId argument even when that argument wasn't present. The new code for ContentProcess::Init() doesn't have to read past aArgc-1 because the mGroupId fix ensures the appModelUserId argument is always present. MozReview-Commit-ID: 8a8k6ABYMgo --HG-- extra : rebase_source : 70695125ee26e67af3337119f4dfc293a0dab74c
2018-03-16 04:23:10 +03:00
return false;
}
Bug 1438678 - Pass early prefs via shared memory instead of the command line. r=bobowen,jld,glandium. This patch replaces the large -intPrefs/-boolPrefs/-stringPrefs flags with a short-lived, anonymous, shared memory segment that is used to pass the early prefs. Removing the bloat from the command line is nice, but more important is the fact that this will let us pass more prefs at content process start-up, which will allow us to remove the early/late prefs split (bug 1436911). Although this mechanism is only used for prefs, it's conceivable that it could be used for other data that must be received very early by children, and for which the command line isn't ideal. Notable details: - Much of the patch deals with the various platform-specific ways of passing handles/fds to children. - Linux and Mac: we use a fixed fd (8) in combination with the new GeckoChildProcessHost::AddFdToRemap() function (which ensures the child won't close the fd). - Android: like Linux and Mac, but the handles get passed via "parcels" and we use the new SetPrefsFd() function instead of the fixed fd. - Windows: there is no need to duplicate the handle because Windows handles are system-wide. But we do use the new GeckoChildProcessHost::AddHandleToShare() function to add it to the list of inheritable handles. We also ensure that list is processed on all paths (MOZ_SANDBOX with sandbox, MOZ_SANDBOX without sandbox, non-MOZ_SANDBOX) so that the handles are marked as inheritable. The handle is passed via the -prefsHandle flag. The -prefsLen flag is used on all platforms to indicate the size of the shared memory segment. - The patch also moves the serialization/deserialization of the prefs in/out of the shared memory into libpref, which is a better spot for it. (This means Preferences::MustSendToContentProcesses() can be removed.) MozReview-Commit-ID: 8fREEBiYFvc --HG-- extra : rebase_source : 7e4c8ebdbcd7d74d6bd2ab3c9e75a6a17dbd8dfe
2018-02-16 09:54:16 +03:00
// Set up early prefs from the shared memory.
base::SharedMemory shm;
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm The current code is a bit of a mess. This patch does the following. - Changes the processing from backwards to forwards. This avoids the need for all the `found` booleans, because if a flag is present multiple times, the last one will naturally override. - Tightens up the checking. It now doesn't use assertions, but instead returns false if any of the options are missing arguments, or have malformed arguments, or any of the mandatory flags are missing. (It assumes that -appdir and -profile are optional.) - Renames the loop variable `idx` as `i`. - Changes `!strcmp(...)` to `strcmp(...) == 0`, because I find that clearer. - Avoids a redundant nsCString when handling -appdir. The patch also tweaks GeckoChildProcessHost::mGroupId, which was buggy. It holds the appModelUserId argument, which XRE_InitChildProcess() always expects is present in the command. But it's only set to a non-empty value in InitWindowsGroupID(), which is only called for plugin processes. So in lots of cases the appModelUserId argument was missing, and a different argument would be interpreted as the appModelUserId argument (seemingly without noticeable ill effect). The patch changes things to mGroupId defaults to "-", which means it's always present in the command. Note: all this explains why the old code for ContentProcess::Init() started processing from argument aArgc, instead of aArgc-1 as you might expect -- it had to read one extra arg in order to see the argument following -appdir, because XRE_InitChildProcess() was decrementing aArgc for the appModelUserId argument even when that argument wasn't present. The new code for ContentProcess::Init() doesn't have to read past aArgc-1 because the mGroupId fix ensures the appModelUserId argument is always present. MozReview-Commit-ID: 8a8k6ABYMgo --HG-- extra : rebase_source : 70695125ee26e67af3337119f4dfc293a0dab74c
2018-03-16 04:23:10 +03:00
if (!shm.SetHandle(*prefsHandle, /* read_only */ true)) {
Bug 1438678 - Pass early prefs via shared memory instead of the command line. r=bobowen,jld,glandium. This patch replaces the large -intPrefs/-boolPrefs/-stringPrefs flags with a short-lived, anonymous, shared memory segment that is used to pass the early prefs. Removing the bloat from the command line is nice, but more important is the fact that this will let us pass more prefs at content process start-up, which will allow us to remove the early/late prefs split (bug 1436911). Although this mechanism is only used for prefs, it's conceivable that it could be used for other data that must be received very early by children, and for which the command line isn't ideal. Notable details: - Much of the patch deals with the various platform-specific ways of passing handles/fds to children. - Linux and Mac: we use a fixed fd (8) in combination with the new GeckoChildProcessHost::AddFdToRemap() function (which ensures the child won't close the fd). - Android: like Linux and Mac, but the handles get passed via "parcels" and we use the new SetPrefsFd() function instead of the fixed fd. - Windows: there is no need to duplicate the handle because Windows handles are system-wide. But we do use the new GeckoChildProcessHost::AddHandleToShare() function to add it to the list of inheritable handles. We also ensure that list is processed on all paths (MOZ_SANDBOX with sandbox, MOZ_SANDBOX without sandbox, non-MOZ_SANDBOX) so that the handles are marked as inheritable. The handle is passed via the -prefsHandle flag. The -prefsLen flag is used on all platforms to indicate the size of the shared memory segment. - The patch also moves the serialization/deserialization of the prefs in/out of the shared memory into libpref, which is a better spot for it. (This means Preferences::MustSendToContentProcesses() can be removed.) MozReview-Commit-ID: 8fREEBiYFvc --HG-- extra : rebase_source : 7e4c8ebdbcd7d74d6bd2ab3c9e75a6a17dbd8dfe
2018-02-16 09:54:16 +03:00
NS_ERROR("failed to open shared memory in the child");
return false;
}
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm The current code is a bit of a mess. This patch does the following. - Changes the processing from backwards to forwards. This avoids the need for all the `found` booleans, because if a flag is present multiple times, the last one will naturally override. - Tightens up the checking. It now doesn't use assertions, but instead returns false if any of the options are missing arguments, or have malformed arguments, or any of the mandatory flags are missing. (It assumes that -appdir and -profile are optional.) - Renames the loop variable `idx` as `i`. - Changes `!strcmp(...)` to `strcmp(...) == 0`, because I find that clearer. - Avoids a redundant nsCString when handling -appdir. The patch also tweaks GeckoChildProcessHost::mGroupId, which was buggy. It holds the appModelUserId argument, which XRE_InitChildProcess() always expects is present in the command. But it's only set to a non-empty value in InitWindowsGroupID(), which is only called for plugin processes. So in lots of cases the appModelUserId argument was missing, and a different argument would be interpreted as the appModelUserId argument (seemingly without noticeable ill effect). The patch changes things to mGroupId defaults to "-", which means it's always present in the command. Note: all this explains why the old code for ContentProcess::Init() started processing from argument aArgc, instead of aArgc-1 as you might expect -- it had to read one extra arg in order to see the argument following -appdir, because XRE_InitChildProcess() was decrementing aArgc for the appModelUserId argument even when that argument wasn't present. The new code for ContentProcess::Init() doesn't have to read past aArgc-1 because the mGroupId fix ensures the appModelUserId argument is always present. MozReview-Commit-ID: 8a8k6ABYMgo --HG-- extra : rebase_source : 70695125ee26e67af3337119f4dfc293a0dab74c
2018-03-16 04:23:10 +03:00
if (!shm.Map(*prefsLen)) {
Bug 1438678 - Pass early prefs via shared memory instead of the command line. r=bobowen,jld,glandium. This patch replaces the large -intPrefs/-boolPrefs/-stringPrefs flags with a short-lived, anonymous, shared memory segment that is used to pass the early prefs. Removing the bloat from the command line is nice, but more important is the fact that this will let us pass more prefs at content process start-up, which will allow us to remove the early/late prefs split (bug 1436911). Although this mechanism is only used for prefs, it's conceivable that it could be used for other data that must be received very early by children, and for which the command line isn't ideal. Notable details: - Much of the patch deals with the various platform-specific ways of passing handles/fds to children. - Linux and Mac: we use a fixed fd (8) in combination with the new GeckoChildProcessHost::AddFdToRemap() function (which ensures the child won't close the fd). - Android: like Linux and Mac, but the handles get passed via "parcels" and we use the new SetPrefsFd() function instead of the fixed fd. - Windows: there is no need to duplicate the handle because Windows handles are system-wide. But we do use the new GeckoChildProcessHost::AddHandleToShare() function to add it to the list of inheritable handles. We also ensure that list is processed on all paths (MOZ_SANDBOX with sandbox, MOZ_SANDBOX without sandbox, non-MOZ_SANDBOX) so that the handles are marked as inheritable. The handle is passed via the -prefsHandle flag. The -prefsLen flag is used on all platforms to indicate the size of the shared memory segment. - The patch also moves the serialization/deserialization of the prefs in/out of the shared memory into libpref, which is a better spot for it. (This means Preferences::MustSendToContentProcesses() can be removed.) MozReview-Commit-ID: 8fREEBiYFvc --HG-- extra : rebase_source : 7e4c8ebdbcd7d74d6bd2ab3c9e75a6a17dbd8dfe
2018-02-16 09:54:16 +03:00
NS_ERROR("failed to map shared memory in the child");
return false;
}
Preferences::DeserializePreferences(static_cast<char*>(shm.memory()),
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm The current code is a bit of a mess. This patch does the following. - Changes the processing from backwards to forwards. This avoids the need for all the `found` booleans, because if a flag is present multiple times, the last one will naturally override. - Tightens up the checking. It now doesn't use assertions, but instead returns false if any of the options are missing arguments, or have malformed arguments, or any of the mandatory flags are missing. (It assumes that -appdir and -profile are optional.) - Renames the loop variable `idx` as `i`. - Changes `!strcmp(...)` to `strcmp(...) == 0`, because I find that clearer. - Avoids a redundant nsCString when handling -appdir. The patch also tweaks GeckoChildProcessHost::mGroupId, which was buggy. It holds the appModelUserId argument, which XRE_InitChildProcess() always expects is present in the command. But it's only set to a non-empty value in InitWindowsGroupID(), which is only called for plugin processes. So in lots of cases the appModelUserId argument was missing, and a different argument would be interpreted as the appModelUserId argument (seemingly without noticeable ill effect). The patch changes things to mGroupId defaults to "-", which means it's always present in the command. Note: all this explains why the old code for ContentProcess::Init() started processing from argument aArgc, instead of aArgc-1 as you might expect -- it had to read one extra arg in order to see the argument following -appdir, because XRE_InitChildProcess() was decrementing aArgc for the appModelUserId argument even when that argument wasn't present. The new code for ContentProcess::Init() doesn't have to read past aArgc-1 because the mGroupId fix ensures the appModelUserId argument is always present. MozReview-Commit-ID: 8a8k6ABYMgo --HG-- extra : rebase_source : 70695125ee26e67af3337119f4dfc293a0dab74c
2018-03-16 04:23:10 +03:00
*prefsLen);
Bug 1438678 - Pass early prefs via shared memory instead of the command line. r=bobowen,jld,glandium. This patch replaces the large -intPrefs/-boolPrefs/-stringPrefs flags with a short-lived, anonymous, shared memory segment that is used to pass the early prefs. Removing the bloat from the command line is nice, but more important is the fact that this will let us pass more prefs at content process start-up, which will allow us to remove the early/late prefs split (bug 1436911). Although this mechanism is only used for prefs, it's conceivable that it could be used for other data that must be received very early by children, and for which the command line isn't ideal. Notable details: - Much of the patch deals with the various platform-specific ways of passing handles/fds to children. - Linux and Mac: we use a fixed fd (8) in combination with the new GeckoChildProcessHost::AddFdToRemap() function (which ensures the child won't close the fd). - Android: like Linux and Mac, but the handles get passed via "parcels" and we use the new SetPrefsFd() function instead of the fixed fd. - Windows: there is no need to duplicate the handle because Windows handles are system-wide. But we do use the new GeckoChildProcessHost::AddHandleToShare() function to add it to the list of inheritable handles. We also ensure that list is processed on all paths (MOZ_SANDBOX with sandbox, MOZ_SANDBOX without sandbox, non-MOZ_SANDBOX) so that the handles are marked as inheritable. The handle is passed via the -prefsHandle flag. The -prefsLen flag is used on all platforms to indicate the size of the shared memory segment. - The patch also moves the serialization/deserialization of the prefs in/out of the shared memory into libpref, which is a better spot for it. (This means Preferences::MustSendToContentProcesses() can be removed.) MozReview-Commit-ID: 8fREEBiYFvc --HG-- extra : rebase_source : 7e4c8ebdbcd7d74d6bd2ab3c9e75a6a17dbd8dfe
2018-02-16 09:54:16 +03:00
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm The current code is a bit of a mess. This patch does the following. - Changes the processing from backwards to forwards. This avoids the need for all the `found` booleans, because if a flag is present multiple times, the last one will naturally override. - Tightens up the checking. It now doesn't use assertions, but instead returns false if any of the options are missing arguments, or have malformed arguments, or any of the mandatory flags are missing. (It assumes that -appdir and -profile are optional.) - Renames the loop variable `idx` as `i`. - Changes `!strcmp(...)` to `strcmp(...) == 0`, because I find that clearer. - Avoids a redundant nsCString when handling -appdir. The patch also tweaks GeckoChildProcessHost::mGroupId, which was buggy. It holds the appModelUserId argument, which XRE_InitChildProcess() always expects is present in the command. But it's only set to a non-empty value in InitWindowsGroupID(), which is only called for plugin processes. So in lots of cases the appModelUserId argument was missing, and a different argument would be interpreted as the appModelUserId argument (seemingly without noticeable ill effect). The patch changes things to mGroupId defaults to "-", which means it's always present in the command. Note: all this explains why the old code for ContentProcess::Init() started processing from argument aArgc, instead of aArgc-1 as you might expect -- it had to read one extra arg in order to see the argument following -appdir, because XRE_InitChildProcess() was decrementing aArgc for the appModelUserId argument even when that argument wasn't present. The new code for ContentProcess::Init() doesn't have to read past aArgc-1 because the mGroupId fix ensures the appModelUserId argument is always present. MozReview-Commit-ID: 8a8k6ABYMgo --HG-- extra : rebase_source : 70695125ee26e67af3337119f4dfc293a0dab74c
2018-03-16 04:23:10 +03:00
Scheduler::SetPrefs(*schedulerPrefs);
mContent.Init(IOThreadChild::message_loop(),
ParentPid(),
*parentBuildID,
IOThreadChild::channel(),
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm The current code is a bit of a mess. This patch does the following. - Changes the processing from backwards to forwards. This avoids the need for all the `found` booleans, because if a flag is present multiple times, the last one will naturally override. - Tightens up the checking. It now doesn't use assertions, but instead returns false if any of the options are missing arguments, or have malformed arguments, or any of the mandatory flags are missing. (It assumes that -appdir and -profile are optional.) - Renames the loop variable `idx` as `i`. - Changes `!strcmp(...)` to `strcmp(...) == 0`, because I find that clearer. - Avoids a redundant nsCString when handling -appdir. The patch also tweaks GeckoChildProcessHost::mGroupId, which was buggy. It holds the appModelUserId argument, which XRE_InitChildProcess() always expects is present in the command. But it's only set to a non-empty value in InitWindowsGroupID(), which is only called for plugin processes. So in lots of cases the appModelUserId argument was missing, and a different argument would be interpreted as the appModelUserId argument (seemingly without noticeable ill effect). The patch changes things to mGroupId defaults to "-", which means it's always present in the command. Note: all this explains why the old code for ContentProcess::Init() started processing from argument aArgc, instead of aArgc-1 as you might expect -- it had to read one extra arg in order to see the argument following -appdir, because XRE_InitChildProcess() was decrementing aArgc for the appModelUserId argument even when that argument wasn't present. The new code for ContentProcess::Init() doesn't have to read past aArgc-1 because the mGroupId fix ensures the appModelUserId argument is always present. MozReview-Commit-ID: 8a8k6ABYMgo --HG-- extra : rebase_source : 70695125ee26e67af3337119f4dfc293a0dab74c
2018-03-16 04:23:10 +03:00
*childID,
*isForBrowser);
mXREEmbed.Start();
#if (defined(XP_MACOSX)) && defined(MOZ_CONTENT_SANDBOX)
mContent.SetProfileDir(profileDir);
#endif
#if defined(XP_WIN) && defined(MOZ_CONTENT_SANDBOX)
SetUpSandboxEnvironment();
#endif
return true;
}
// Note: CleanUp() never gets called in non-debug builds because we exit early
// in ContentChild::ActorDestroy().
void
ContentProcess::CleanUp()
{
mXREEmbed.Stop();
}
} // namespace dom
} // namespace mozilla