This will let us manipulate it from multiple threads in a future patch.
MozReview-Commit-ID: 2AOgho8SEX9
--HG--
extra : rebase_source : 49e7d82b38e6f7b7eb9f6cb7c61a2b41d34f2bdc
This code is unused now that ReadLockDescriptors are not sent in layer transactions.
--HG--
extra : rebase_source : 8cd25541b22c3151e2dbd2f8ea6d1119e2f26c94
extra : source : 99a2d26d1ba82ad34a6c27641500a424cda015c3
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
This changes the lifecycle and API for TextureReadLock to fix file descriptor exhaustion
crashes. These changes are partially superficial and mostly align the API of TextureReadLocks
with their actual usage.
The changes are:
1. Create the TextureReadLock in the TextureClient constructor so it's available before IPC creation
a. This is superficial as EnableReadLock was always called before IPC creation
2. Send the ReadLockDescriptor in the PTextureConstructor message and close the file handle
3. Receive the ReadLockDescriptor in TextureHost and close the file handle
4. Send a boolean flag in layer transactions if the texture is read locked instead of a descriptor
5. Use a boolean flag in TextureHost to determine if the ReadLock must be unlocked instead of a nullptr
I believe that we can remove the InitReadLocks code from LayerTransaction as that was added to
prevent file descriptor limits in IPDL messages and is no longer needed with this change. But
that is a non-essential change and this patch is already big enough.
MozReview-Commit-ID: DzHujrOQejH
--HG--
extra : rebase_source : 3bdd7c9bc8edfdc386faad8a9e59ad7dc18ed91d
Switch the order of the IPC FD argument and the crash FD argument in
e10s calls, because the IPC FD is the primary FD, and the crash FD
should be grouped with the crash annotation FD.
MozReview-Commit-ID: CAVyYAIIBPm
--HG--
extra : rebase_source : 596f590443f727d1a79582202eed122f79ae85cf
Because Interceptors disable COM garbage collection to improve performance, they never receive Release calls from remote clients.
If the object can be shut down while clients still hold a reference, this function can be used to force COM to disconnect all remote connections (using CoDisconnectObject) and thus release the associated references to the Interceptor, its target and any objects associated with the HandlerProvider.
A HandlerProvider::DisconnectHandlerRemotes method also had to be added to allow HandlerProviders to disconnect clients for their own objects.
MozReview-Commit-ID: JaxEkOtrP1M
--HG--
extra : rebase_source : bc7a4ab79458eaaddcef8df74ff4d6f685fbfdce
extra : histedit_source : 087f17f09a0c0e1c8e3b5f6d9690f331c15f0b95
COM queries for special interfaces such as IFastRundown when creating a marshaler.
We don't want these being dispatched to the main thread, since this would cause a deadlock on mStdMarshalMutex if the main thread is also querying for IMarshal.
MozReview-Commit-ID: EQcN8Zhewjh
--HG--
extra : rebase_source : 40c39edce139f66fdb43b539b1d6fb0acb00d755
This is important as these includes are often used to define ParamTraits
implementations which are needed to serialize struct members and
parameters. The place where the code which uses these implementations
will be moving from the protocol where they are used to the file where
the structs are defined, which means we need to includes these files
there.
MozReview-Commit-ID: H1wqgyv5mel
MainThreadInvoker queues both a Gecko runnable and an APC to the main thread to deal with different ways in which the main thread can block.
However, the main thread doesn't check for APCs very often any more.
This means that the APC's reference to the SyncRunnable doesn't get cleaned up for a long time, thus leaking memory.
To work around this, we:
1. Queue an APC wich does the actual work.
2. Post a Gecko runnable (which always runs).
If the APC hasn't run, the Gecko runnable runs it.
Otherwise, it does nothing.
MozReview-Commit-ID: L0P4rMBnlaZ
--HG--
extra : rebase_source : 3af871cf59e94818963e15881217218ef2b42b6c
Because Interceptors disable COM garbage collection to improve performance, they never receive Release calls from remote clients.
If the object can be shut down while clients still hold a reference, this function can be used to force COM to disconnect all remote connections (using CoDisconnectObject) and thus release the associated references to the Interceptor, its target and any objects associated with the HandlerProvider.
A HandlerProvider::DisconnectHandlerRemotes method also had to be added to allow HandlerProviders to disconnect clients for their own objects.
MozReview-Commit-ID: JaxEkOtrP1M
--HG--
extra : rebase_source : 2262af8fc3cb1aec8d9c8fc2762f3d61e188cb37
Switch the order of the IPC FD argument and the crash FD argument in
e10s calls, because the IPC FD is the primary FD, and the crash FD
should be grouped with the crash annotation FD.
MozReview-Commit-ID: CAVyYAIIBPm
--HG--
extra : rebase_source : 02bf7337fa9a6d1194809c224acb4a2690fd87a3
Removing #define XRE_DONT_PROTECT_DLL_LOAD from plugin-container.cpp and xpcshell.cpp allows the #included nsWindowsWMain.cpp to protect DLL loads much earlier in the plugin process startup.
MozReview-Commit-ID: HbgyfvljvFs
--HG--
extra : rebase_source : dccdabb2e5bee4472d5aef9400a58cb0e397c112
extra : histedit_source : da248fc6fbdf96f30979f3a0396aefcf4bfcd5d9
You'd think that MesHandleFree would free the buffer, since it was created by RPC, but it doesn't.
Therefore, we must free it ourselves using midl_user_free.
MozReview-Commit-ID: 9KzWTngFEEq
--HG--
extra : rebase_source : 6bee3903f619ec1cb1569ebf1df2ddef9da6b901
Do not pass command line arguments to child processes that they won't read.
MozReview-Commit-ID: soj1hRygNw
--HG--
extra : rebase_source : 13501d2f12a0be910323465f589386e7c956e41a
When an object is aggregated, doing a QI to anything other than IUnknown on the inner object AddRefs the outer object.
Thus, before releasing our reference to the inner IUnknown (and thus destroying it), we *must* release any references to interfaces queried from it.
Otherwise, any pointers to interfaces of the inner object would be invalidated.
MozReview-Commit-ID: KXsA8Sagx6G
--HG--
extra : rebase_source : f1dca4ee71f2ed49c8ba19c12862f2b4f9881fca
These conditions are rare and do indicate a problem which breaks accessibility.
However, we aren't getting any closer to diagnosing these as a result of these crashes, so they cause user pain without any gain to us.
MozReview-Commit-ID: D9U4et3Bg7d
--HG--
extra : rebase_source : a81263a0ef97a8ed87129d15ef30ded3005e740c
These conditions are rare and do indicate a problem which breaks accessibility.
However, we aren't getting any closer to diagnosing these as a result of these crashes, so they cause user pain without any gain to us.
MozReview-Commit-ID: D9U4et3Bg7d
--HG--
extra : rebase_source : a81263a0ef97a8ed87129d15ef30ded3005e740c
This removes the need for the content process to have permissions to create new
files on macOS, allowing more aggressive sandboxing.
MozReview-Commit-ID: 8agL5jwxDSL
--HG--
extra : rebase_source : 17ebcef3e9d24f3d4e7515e3fae95e65cef76a79
This removes the need for the content process to have permissions to create new
files on macOS, allowing more aggressive sandboxing.
MozReview-Commit-ID: 8agL5jwxDSL
--HG--
extra : rebase_source : 215577cd5ced3994a4c3345377b3feedea07e886
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
Support for accept4 and arc4random_buf depends on which set of NDK
headers we're using. accept4 is supported for API >= 21 for unified and
non-unified headers. arc4random_buf is supported for API >= 21 if using
non-unified headers, and it's always supported if using unified headers
(the unified headers provide shims for API < 21).
MozReview-Commit-ID: FY8n5jWXB1K
--HG--
rename : ipc/chromium/src/third_party/libevent/patches/android-arc4random-buf.patch => ipc/chromium/src/third_party/libevent/patches/android-api-level.patch
extra : rebase_source : 45ec28ca03ba877d9e0911bde081df7d9cb2d3d2
Support for accept4 and arc4random_buf depends on which set of NDK
headers we're using. accept4 is supported for API >= 21 for unified and
non-unified headers. arc4random_buf is supported for API >= 21 if using
non-unified headers, and it's always supported if using unified headers
(the unified headers provide shims for API < 21).
MozReview-Commit-ID: FY8n5jWXB1K
--HG--
rename : ipc/chromium/src/third_party/libevent/patches/android-arc4random-buf.patch => ipc/chromium/src/third_party/libevent/patches/android-api-level.patch
extra : rebase_source : a8974cb1e8e71a8c951754ca9902fff28c099031
This fix is completely speculative, but I have strong reason to believe that
we are having lifetime issues, and that refcount stabilization might be coming
into play.
The situation is this:
Suppose we're aggregating an object, so we pass |this| as the outer IUnknown.
The inner object might perform AddRef() and Release() on |this| during its
initialization.
But if we're in the process of creating the outer object, that refcount might
not yet have been incremented by 1, so the inner object's invocation of the
outer object's Release() could trigger a deletion.
The way around this is to temporarily bump the refcount when aggregating another
object. The key, though, is to not do this via AddRef() and Release(), but by
direct maniuplation of the refcount variable, so that we don't trigger any of
the self-deletion stuff.
MozReview-Commit-ID: 3WA2AJvb6jY
--HG--
extra : rebase_source : ab05a52760541a4ab11f1245a5ddeae938998047
The FunctionBroker is a special kind of FunctionHook that brokers the hooked function on another process. In the child process, it uses the FunctionBrokerChild to request that the FunctionBrokerParent run a function and return the response. It handles most cases of parameter, return value and error marshaling on its own. It also guarantees that requests are issued from the proper thread.
The FunctionBroker actors allow the NPAPI process (child) to run methods on the main process (parent). Both the parent and the child run dedicated threads for this task -- this is a top-level protocol.
Namespace isolation is now handled by using clone() at process creation
time, rather than calling unshare.
pthread_atfork will no longer apply to sandboxed child processes.
The two significant uses of it in Firefox currently are to (1) make
malloc work post-fork, which we already avoid depending on in IPC and
sandboxing, and (2) block SIGPROF while forking, which is taken care of;
see SandboxFork::Fork for details. Note that if we need pthread_atfork
in the future it could be emulated by symbol interposition.
clone() is called via glibc's wrapper, for increased compatibility vs.
invoking the syscall directly, using longjmp to recover the syscall's
fork-like semantics the same way Chromium does; see comments for details.
The chroot helper is reimplemented; the general approach is similar,
but instead of a thread it's a process cloned with CLONE_FS (so the
filesystem root is shared) from the child process before it calls
exec, so that it still holds CAP_SYS_CHROOT in the newly created user
namespace. This does mean that it will retain a CoW copy of the
parent's address space until the child starts sandboxing, but that is a
relatively short period of time, so the memory overhead should be small
and short-lived.
The chrooting now happens *after* the seccomp-bpf policy is applied;
previously this wasn't possible because the chroot thread would have
become seccomp-restricted and unable to chroot. This fixes a potential
race condition where a thread could try to access the filesystem after
chrooting but before having its syscalls intercepted for brokering,
causing spurious failure. (This failure mode hasn't been observed in
practice, but we may not be looking for it.)
This adds a hidden bool pref, security.sandbox.content.force-namespace,
which unshares the user namespace (if possible) even if no sandboxing
requires it. It defaults to true on Nightly and false otherwise, to
get test coverage; the default will change to false once we're using
namespaces by default with content.
MozReview-Commit-ID: JhCXF9EgOt6
--HG--
rename : security/sandbox/linux/LinuxCapabilities.cpp => security/sandbox/linux/launch/LinuxCapabilities.cpp
rename : security/sandbox/linux/LinuxCapabilities.h => security/sandbox/linux/launch/LinuxCapabilities.h
extra : rebase_source : f37acacd4f79b0d6df0bcb9d1d5ceb4b9c5e6371
inline is never set so cgen never emits inline.
MozReview-Commit-ID: BDL6BV8906t
--HG--
extra : rebase_source : aa51cda34db36ba08622d9940402cea14617c74a
never_inline is never set so cgen never emits MOZ_NEVER_INLINE.
MozReview-Commit-ID: HS7qw7D4lBC
--HG--
extra : rebase_source : 2eae9e3a7a0c95d94986283fabe670d5decec3c3
pure or override implies virtual. static is mutually exclusive with virtual (and pure and override). Combining these types into a "method specifier" enum simplifies the code and prevents bogus states like virtual=0 and pure=1.
MozReview-Commit-ID: IFeuvbp1RIo
--HG--
extra : rebase_source : d423d168a8b3a3d60cabd0f5e58fd03c6f655baf
We had to force-include Char16.h to simulate char16_t on older MSVC versions.
But it is no longer the case. We should not rebuild the world whenever we
touch this file.
MozReview-Commit-ID: 1XY7tQD8LoK
--HG--
extra : rebase_source : a08ccfc9b6a4abf90f6f8b97a42079865724c9ec
CPU is only used on Windows, for TimeTicks::HighResNow, but the latter
is not used, so remove them all.
MozReview-Commit-ID: CvV1gMrVRA5
--HG--
extra : rebase_source : 2a512e2cfbe7d734a2c806214a2a96f79cbc9f11
CPU is only used on Windows, for TimeTicks::HighResNow, but the latter
is not used, so remove them all.
MozReview-Commit-ID: CvV1gMrVRA5
--HG--
extra : rebase_source : 60ddcf6ea5542f4526a23d739a2fe754219e5b9f
This patch requires that each instance of IPC's RunnableFunction is
passed in a name, like the non-IPC RunnableFunction.
MozReview-Commit-ID: Atu1W3Rl66S
--HG--
extra : rebase_source : f932d7597a26a3f0c4246b3a95df638860d3d32d
PluginMessageUtils.h was bootlegging base/shared_memory.h via transport_dib.h
MozReview-Commit-ID: CPGxu2lpdj0
--HG--
extra : rebase_source : 796c747a4a125dddc2a0685f1e0d0152ac3ef74f
This removes an unnecessary level of indirection by replacing all
nsStringGlue.h instances with just nsString.h.
--HG--
extra : rebase_source : 340989240af4018f3ebfd92826ae11b0cb46d019
Summary:
We currently have a single WebAuthnManager instance per process that's shared
between all CredentialContainers. That way the nsPIDOMWindowInner parent has
to be tracked by the transaction, as multiple containers could kick off
requests simultaneously.
This patch lets us we have one WebAuthnManager instance per each
CredentialsContainer and thus each nsPIDOMWindowInner. This matches the current
U2F implementation where there is one instance per parent window too.
This somewhat simplifies the communication diagram (at least in my head), as
each U2F/WebAuthnManager instance also has their own TransactionChild/Parent
pair for IPC protocol communication. The manager and child/parent pair are
destroyed when the window is.
Reviewers: jcj
Reviewed By: jcj
Bug #: 1421616
Differential Revision: https://phabricator.services.mozilla.com/D305
Summary:
We currently have a single WebAuthnManager instance per process that's shared
between all CredentialContainers. That way the nsPIDOMWindowInner parent has
to be tracked by the transaction, as multiple containers could kick off
requests simultaneously.
This patch lets us we have one WebAuthnManager instance per each
CredentialsContainer and thus each nsPIDOMWindowInner. This matches the current
U2F implementation where there is one instance per parent window too.
This somewhat simplifies the communication diagram (at least in my head), as
each U2F/WebAuthnManager instance also has their own TransactionChild/Parent
pair for IPC protocol communication. The manager and child/parent pair are
destroyed when the window is.
Reviewers: jcj
Reviewed By: jcj
Bug #: 1421616
Differential Revision: https://phabricator.services.mozilla.com/D305
Also ensure we're more consistent about having two blank lines after these methods.
MozReview-Commit-ID: 2SXXjDuMW4u
--HG--
extra : rebase_source : 05279ceab3aa32d1e577ea02ccd113180bb55792
There's already a typedef for MessageChannel, so use that instead of
Channel. Also, use IProtocol and not ProtocolBase or ChannelListener,
for simplicity.
MozReview-Commit-ID: 2zCjTpPTW4L
--HG--
extra : rebase_source : eed8d6d51a512ac85f6b4962fc12591bf81c2981
This method is now trivial, so we can inline a few things. This
removes the only callers of sendSems(), so remove that, too.
MozReview-Commit-ID: Bb4EF9M56ut
--HG--
extra : rebase_source : dedf31aa225361e31122362aefc76940edbf25f3
This also changes URIUtils.cpp:DeserializeURI() to use the mutator to instantiate new URIs, instead of using their default constructor.
MozReview-Commit-ID: JQOvIquuQAP
--HG--
extra : rebase_source : e146624c5ae423f7f69a738aaaafaa55dd0940d9
If QueryHandlerInterface returns E_NOINTERFACE, the proxy will be queried for the interface.
However, the handler might know that the interface is definitely not available and could thus avoid a pointless cross-process call.
To facilitate this, the handler can now return S_FALSE to signal that the proxy should not be queried, thus immediately returning E_NOINTERFACE to the client.
MozReview-Commit-ID: 4RtBsA9BTOV
--HG--
extra : rebase_source : 4b0dcb16c469361c1944b24568ceb83fd0ac09c1
Currently if you write an async IPDL method which has a return value, we expose
a SendXXX method which returns a MozPromise. This MozPromise can then be
->Then-ed to run code when it is resolved or rejected.
Unfortunately, using this API loses ordering guarantees which IPDL provides.
MozPromise::Then takes an event target, which the resolve runnable is dispatched
to. This means that the resolve callback's code doesn't have any ordering
guarantees relative to the processing of other IPC messages coming over the same
protocol.
This adds a new overload to SendXXX with two additional arguments, a lambda
callback which is called if the call succeeds, and a lambda callback which is
called if the call fails. These will be called in order with other IPC messages
sent over the same protocol.
MozReview-Commit-ID: FZHJJaSDoZy
This is a hack that was added back when the chromium ipc codebase was
imported, but that shouldn't be required anymore. The mozalloc operator
new is gotten through stl wrapping these days.
This patch uses MozURL in ServiceWorkerRegistrar and in DBScheme to obtain the
origin of a URL. This is safe because the URL is always http/https/ftp.
It also changes the serialization of Principal in nsJSPrincipals in order to
pass the originNoSuffix together with the OriginAttributes and the spec.
This patch moves handling of the "MOZ_DISABLE_CONTENT_SANDBOX" environment
variable into GetEffectiveContentSandboxLevel. It also introduces
IsContentSandboxEnabled and ports many users of GetEffectiveContentSandboxLevel
to use it.
MozReview-Commit-ID: 4CsOf89vlRB
--HG--
extra : rebase_source : b9130f522e860e6a582933799a9bac07b771139b
This patch moves handling of the "MOZ_DISABLE_CONTENT_SANDBOX" environment
variable into GetEffectiveContentSandboxLevel. It also introduces
IsContentSandboxEnabled and ports many users of GetEffectiveContentSandboxLevel
to use it.
MozReview-Commit-ID: 4CsOf89vlRB
--HG--
extra : rebase_source : 10234bd7d837eae8dc915e4a0c0a37040fd0a280
MOZ_CRASH_UNSAFE_PRINTF causes data collection because crash strings are annotated to crash-stats and are publicly visible. Firefox data stewards must do data review on usages of this macro. However, all the crash strings this patch collects with MOZ_CRASH_UNSAFE_PRINTF are already collected with NS_RUNTIMEABORT.
MozReview-Commit-ID: 5ujXa9MHH5Z
--HG--
extra : rebase_source : 1367e6ac3c6085341e36cb0859d91417245ea472
extra : source : 3edeb64a40afd79d5c01ae0f0d3ab2777a2e744b
This also enables the crash reporter on the MinGW build, as this is the
only thing blocking that from working.
MozReview-Commit-ID: Hygd7UUQvwl
--HG--
extra : rebase_source : a4a12b8edaa5b1fba869d6f7c21fc8444be2d9d7
Summary:
This patch fixes the reported leak of U2FTransactionChild instances in the
content process by introducing a WebAuthnTransactionChildBase class that both
WebAuthnTransactionChild and U2FTransactionChild inherit from.
This base class is responsible for proper refcounting. In
BackgroundChildImpl::DeallocPWebAuthnTransactionChild() we currently always
cast to WebAuthnTransactionChild, that will work only for the WebAuthn API. We
can now cast to WebAuthnTransactionChildBase to make this work for U2F as well.
Reviewers: jcj
Reviewed By: jcj
Bug #: 1412408
Differential Revision: https://phabricator.services.mozilla.com/D179
And remove unreachable code after MOZ_CRASH_UNSAFE_OOL().
MOZ_CRASH_UNSAFE_OOL causes data collection because crash strings are annotated to crash-stats and are publicly visible. Firefox data stewards must do data review on usages of this macro. However, all the crash strings this patch collects with MOZ_CRASH_UNSAFE_OOL are already collected with NS_RUNTIMEABORT.
MozReview-Commit-ID: IHmJfuxXSqw
--HG--
extra : rebase_source : 031f30934b58a7b87f960e57179641d44aefe5c5
extra : source : fe9f638a56a53c8721eecc4273dcc074c988546e
And remove unreachable code after MOZ_CRASH().
MozReview-Commit-ID: 6ShBtPRKYlF
--HG--
extra : rebase_source : 0fe45a59411bda663828336e2686707b550144ae
extra : source : 8473fd7333d2abe1ea1cc176510c292a5b34df45
StripHandlerFromOBJREF shortens the OBJREF by sizeof(CLSID), so it needs to seek the stream back after tweaking the OBJREF.
Previously, this was done using a relative seek.
Unfortunately, for some reason I can't fathom on Windows 7, this doesn't work when marshaling for VT_DISPATCH.
The Seek call succeeds, but either does nothing or sets the stream position to a garbage value.
Instead, we now use an absolute seek, which seems to behave.
This was breaking IAccessible::accNavigate and AccessibleChildren on Windows 7.
MozReview-Commit-ID: FEH93oiyP5R
--HG--
extra : rebase_source : b15db60da888b49cbd371bc5c8311577a2c7ece4
This was used to support cross-architecture NPAPI plugins on OS X, but
we stopped supporting that in 54 (bug 1339182).
MozReview-Commit-ID: 2BcWYD6mguY
--HG--
extra : rebase_source : 6e509a3cc1f356ccd24f1459c43bc8fb66d7b0f4
This patch adds two additional fields to each mscom log entry: The first is
the duration, in microseconds, of time spent in mscom overhead when executing
a call from the MTA on behalf of a remote client.
The second field is the duration, in microseconds, of time spent actually
executing the method within Gecko itself.
(In other words, the sum of the two fields will equal the total duration of
time spent executing the call.)
MozReview-Commit-ID: EhFieEPrhE5
As its original comments indicate, SetAllFDsToCloseOnExec has an
unavoidable race condition if another thread creates file descriptors
during launch. Instead, use POSIX_SPAWN_CLOEXEC_DEFAULT, which is an
Apple-specific extension to posix_spawn that accomplished the desired
effect atomically.
This patch also introduces some RAII to simplify cleanup in error cases.
MozReview-Commit-ID: 6oHggs77AiY
--HG--
extra : rebase_source : a9391031a95fee4977af800ca993871277db51ce
The current API makes the life time and ownership of the result array unclear
without careful reading. The result array is always owned by the principal,
and its lifetime tied to the lifetime of the principal itself. Returning a
const array reference makes this clear, and should prevent callers from
accidentally modifying the returned array.
MozReview-Commit-ID: 3f8mhynkKAj
--HG--
extra : source : 237acf2879f6222bc4b076c377bf026d18a6ebef
extra : amend_source : dfaf6e88e3c4758f7fdcf7fb422d457edafab1b7
The current API makes the life time and ownership of the result array unclear
without careful reading. The result array is always owned by the principal,
and its lifetime tied to the lifetime of the principal itself. Returning a
const array reference makes this clear, and should prevent callers from
accidentally modifying the returned array.
MozReview-Commit-ID: 3f8mhynkKAj
--HG--
extra : rebase_source : d2a5e0862f8c964fb5a3e46b50c2e9629b218699
extra : amend_source : 27d7a7ef5da6fe2aa1104009b6ee067465db73e1
ChildPrivileges is a leftover from the B2G process model; it's now
mostly unused, except for the Windows sandbox using it to carry whether
a content process has file:/// access.
In general, when sandboxing needs to interact with process launch, the
inputs are some subset of: the GeckoProcessType, the subtype if content,
various prefs and even GPU configuration; and the resulting launch
adjustments are platform-specific. And on some platforms (e.g., OS X)
it's all done after launch. So a simple enum used cross-platform isn't
a good fit.
MozReview-Commit-ID: K31OHOpJzla
--HG--
extra : rebase_source : 3928b44eb86cd076bcac7897536590555237b76b
This is mostly based on the BSD version, which in turn is more or less
the Mac version minus some race conditions. The Linux version does
something similar, but more verbosely and (at least in my opinion) is
harder to follow. Some changes have been made, mainly to use C++11
features like UniquePtr.
MozReview-Commit-ID: 3Gv4DKCqWvu
--HG--
extra : rebase_source : 972264a778b9361d1259851554b5b7ae8f3dcdc6
Currently the Gecko Profiler defines a moderate amount of stuff when
MOZ_GECKO_PROFILER is undefined. It also #includes various headers, including
JS ones. This is making it difficult to separate Gecko's media stack for
inclusion in Servo.
This patch greatly simplifies how things are exposed. The starting point is:
- GeckoProfiler.h can be #included unconditionally;
- everything else from the profiler must be guarded by MOZ_GECKO_PROFILER.
In practice this introduces way too many #ifdefs, so the patch loosens it by
adding no-op macros for a number of the most common operations.
The net result is that #ifdefs and macros are used a bit more, but almost
nothing is exposed in non-MOZ_GECKO_PROFILER builds (including
ProfilerMarkerPayload.h and GeckoProfiler.h), and understanding what is exposed
is much simpler than before.
Note also that in BHR, ThreadStackHelper is now entirely absent in
non-MOZ_GECKO_PROFILER builds.
Avoid going through GeckoAppShell and move the start child process JNI
call directly to GeckoProcessManager.
MozReview-Commit-ID: KU62TiHVQJX
--HG--
extra : rebase_source : 0e8546da502257e1c59bc00b79f50c79a314f3e6
After the previous patch, all that is needed to pass eslint is some
whitespace fixes I generated using:
./mach eslint --fix ipc
The .eslintrc.js file makes eslint expect XPCShell global variables.
With those two changes, eslint can be enabled for the ipc/ directory.
MozReview-Commit-ID: BqSICp2iV6O
--HG--
extra : rebase_source : ccab8be9fc1ae1116ae55631d3978c39d35cad05
I don't fully understand what this test is trying to do, but as far as
I can see, test_ipcshell_child.js does nothing when loaded from
test_ipcshell.js besides define a few variables, so just define them
directly in test_ipcshell.js. I am doing this because eslint does not
like the way the test is currently written: the definition of runtime
in another file confuses it, and it does not like the assignment to
run_test.
MozReview-Commit-ID: Ek0HY9n49eZ
--HG--
extra : rebase_source : 5c99b20afe93c085a198e7824e82207be347f26b
Never store names in Message. One can get string names from
Message::name() or use IPC::StringFromIPCMessageType() when only
message id is available.
MozReview-Commit-ID: 15ksx6SE90c
--HG--
extra : rebase_source : 1a041dc365b7f42edd540d8c7a4dfd8912e48921
xpcshell can sometimes create and then almost immediately kill the GPU process. This can
cause the connection state of GPUParent's message channel to be in error or closed
when it attempts to send its build ID. In this case we should ignore the request
because the process will soon close.
MozReview-Commit-ID: EAupU844iFo
--HG--
extra : histedit_source : df05a01df5ad095b4e3c91e0e038d4e145da5f9d
The NS_LITERAL_CSTRING macro creates a temporary nsLiteralCString to encapsulate the string literal and its length, but AssignLiteral() can determine the string literal's length at compile-time without nsLiteralCString.
MozReview-Commit-ID: B5Y8KyExPQ8
--HG--
extra : rebase_source : e27b266c145daa5acd887e998c6d5b408101e1db
extra : source : 33f49977a33cbdb1c7127871b940eefccc018f65