Having two classes in the inheritance chain inherit from SupportsWeakPtr
now won't compile, but you can use WeakPtr<Derived> when any base class
inherits from SupportsWeakPtr.
Differential Revision: https://phabricator.services.mozilla.com/D83674
The Chromium-derived IPC code was, as far as I can tell, originally
designed for Windows and assumed that channels would be named pipes,
managed and connected to via `std::wstring` paths. The port to Unix,
however, used unnamed `socketpair()` and passed them directly from
process to process, so it has no use for these channel IDs... but it
still computes and propagates them, even though they're not used, using
deprecated wide-string APIs.
This patch introduces a typedef for an abstract channel ID, which is a
`wstring` on Windows and an empty struct on Unix, to allow removing the
string code where it's not needed without needing to completely redesign
the channel abstraction.
Differential Revision: https://phabricator.services.mozilla.com/D72260
Chromium's fix for CVE-2011-3079 added an optional prefix parameter for
channel IDs, but we've never used it and have no plans to. (Chromium
itself doesn't appear to have used it except with the prefixes "gpu"
and "nacl", and the code has since been removed completely in favor of
Mojo.) So let's simplify things and remove it.
Differential Revision: https://phabricator.services.mozilla.com/D84276
This "create a pipe" operation has a mode where, on Unix, it doesn't
create a new transport but rather uses a hard-coded fd for the initial
IPC channel in a child process. (It was originally written for Windows
and the assumption of using named pipes and pathnames for everything.)
That seems like a footgun, so this patch checks for trying to "create"
that pipe twice. However, it doesn't check for accidentally calling it
in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D72259
The PipeMap class tries to simulate the Windows channel model (named
pipes that the client opens by a pathname) on Unix. However, it's
effectively dead code -- the map is empty except in some unit tests that
we never imported.
What we do is generate a "channel ID" with string formatting, then don't
pass it to the child or ever insert anything into the map, then the child
looks up an empty string and doesn't find it, so it uses the hard-coded
fixed fd for the initial channel.
Basically, it does nothing except maybe confuse unfamiliar readers, so
let's get rid of it.
Differential Revision: https://phabricator.services.mozilla.com/D72258
* Use clearer pref names.
* Default (and only support) IPDL dispatching.
* Make DispatchCommands async-only.
* Sync ipdl command per sync webgl entrypoint.
* Eat the boilerplate cost, since there's not too many.
* Run SerializedSize off same path as Serialize.
* All shmem uploads go through normal DispatchCommands.
* Defer pruning of dead code for now so we can iterate quickly.
* Use Read/Write(begin,end) instead of (begin,size).
* This would have prevented a bug where we read/wrote N*sizeof(T)*sizeof(T).
Differential Revision: https://phabricator.services.mozilla.com/D81495
WebRender makes extensive use of shared memory buffers, particularly for
images decoded in the content process. These images can be arbitrarily
large, and there being insufficient memory for an allocation must be
handled gracefully.
On Linux, we will currently crash with a SIGBUS signal during image
decoding instead of just displaying the broken image tag. This is
because the pages backing the shared memory are only allocated when we
write to them. This blocks shipping WebRender on Linux.
This patch uses posix_fallocate to force the reservation of the pages,
and allows failing gracefully if they are unavailable.
Differential Revision: https://phabricator.services.mozilla.com/D80650
CVE-2018-4435 (https://crbug.com/project-zero/1671) was fixed in macOS
10.12 and up, but when we added uses of shm_open that would be affected
by it we still supported 10.9, so we added a workaround that tests for
the bug (by trying to exploit it) and falls back to the slower
alternative of temporary files if necessary.
The minimum supported version is now 10.12, and we've already
committed changes (e.g., to sandboxing) that would break the browser
on older versions, so we can remove this code. Note that we also have
cross-platform gtests that check for this type of bug, so we'll have some
warning if it's ever reintroduced.
Differential Revision: https://phabricator.services.mozilla.com/D83197
CLOSED TREE
Backed out changeset 51d7c644a1e6 (bug 1650163)
Backed out changeset 3d2b6908447a (bug 1650163)
Backed out changeset 79141707d47b (bug 1650163)
We'll never read more than MAX_DESCRIPTORS_PER_MESSAGE file descriptors in a
single message, so size the buffer based on that value.
Differential Revision: https://phabricator.services.mozilla.com/D79162
NS_INLINE_DECL_REFCOUNTING macro doesn't properly work when the object is used on a thread that isn't backed by a single PRThread (such as TaskQueue). See bug 1648031.
The resolution of this issue is rather complex, and outside the scope of this series of change.
So for now, we create a new macro NS_INLINE_DECL_REFCOUNTING_ONEVENTTHREAD which will use a different mechanism to ensure the thread-safe usage of a class.
Differential Revision: https://phabricator.services.mozilla.com/D81269
The speedup here is not great because the Python/IPDL parser overhead is
very high, but this cuts ~10 seconds off a `-j12` build (~15s -> 4s) on
my machine.
Differential Revision: https://phabricator.services.mozilla.com/D81751
This adds 3 new profiler markers for each IPC message:
* One just before the first byte is sent over the IPC channel
* One just after the last byte is sent over the IPC channel
* One just after the last byte is received from the IPC channel
With the already-existing IPC markers (for when SendXXX and RecvXXX are
called), this allows us to calculate the following statistics:
* Send thread latency
* IPC send duration
* IPC recv latency
* Recv thread latency
For more information on how this is presented in the UI, see:
<https://github.com/firefox-devtools/profiler/pull/2535>.
Differential Revision: https://phabricator.services.mozilla.com/D70790
We want it to returning the actual nsThread if that's where the MessageLoop would dispatch its tasks; otherwise return the MessageLoop's EventTarget
Depends on D80357
Differential Revision: https://phabricator.services.mozilla.com/D80811
NS_INLINE_DECL_REFCOUNTING macro doesn't properly work when the object is used on a thread that isn't backed by a single PRThread (such as TaskQueue). See bug 1648031.
The resolution of this issue is rather complex, and outside the scope of this series of change.
So for now, we create a new macro NS_INLINE_DECL_REFCOUNTING_ONEVENTTHREAD which will use a different mechanism to ensure the thread-safe usage of a class.
Differential Revision: https://phabricator.services.mozilla.com/D81269
We want it to returning the actual nsThread if that's where the MessageLoop would dispatch its tasks; otherwise return the MessageLoop's EventTarget
Depends on D80357
Differential Revision: https://phabricator.services.mozilla.com/D80811
We move OnStartRequest from PHttpChannel to PHttpBackgroundChannel, thus adjusting
message-metadata.ini
Depends on D76970
Differential Revision: https://phabricator.services.mozilla.com/D76971
This moves it near the cross-process `PContent` actor, and makes it more clear
that this actor is only intended to be used for DOM things.
Differential Revision: https://phabricator.services.mozilla.com/D80581
This moves it near the cross-process `PContent` actor, and makes it more clear
that this actor is only intended to be used for DOM things.
Differential Revision: https://phabricator.services.mozilla.com/D80581
We move OnStartRequest from PHttpChannel to PHttpBackgroundChannel, thus adjusting
message-metadata.ini
Depends on D76970
Differential Revision: https://phabricator.services.mozilla.com/D76971
Before P1, GetCurrentThreadSerialEventTarget would have always returned the same data as NS_GetCurrentThread, making the comment incorrect Now it will properly return the running TaskQueue if any.
This change of name more clearly exposes what they are doing, as we aren't always dealing with threads directly; but a nsISerialEventTarget
Differential Revision: https://phabricator.services.mozilla.com/D80354
There's no other change than definition changes. All callers are actually passing nsISerialEventTarget.
Depends on D80423
Differential Revision: https://phabricator.services.mozilla.com/D80424
To intercept COM IPC, we provide an `IChannelHook` interface to
`CoRegisterChannelHook`, which gives us notifications about COM IPC that we can
use to insert profiler markers. Note that `IChannelHook` is not documented on
MSDN, however it is defined in the SDK header files.
When the profiler is available, once XPCOM is up:
* If the profiler is active, we immediately register the channel hook;
* Otherwise we register an observer and hold off on registering the hook until
the profiler is started, at which point we register the hook and remove the
observer.
Differential Revision: https://phabricator.services.mozilla.com/D80053
To intercept COM IPC, we provide an `IChannelHook` interface to
`CoRegisterChannelHook`, which gives us notifications about COM IPC that we can
use to insert profiler markers. Note that `IChannelHook` is not documented on
MSDN, however it is defined in the SDK header files.
When the profiler is available, once XPCOM is up:
* If the profiler is active, we immediately register the channel hook;
* Otherwise we register an observer and hold off on registering the hook until
the profiler is started, at which point we register the hook and remove the
observer.
Differential Revision: https://phabricator.services.mozilla.com/D80053
The change to MessageChannel::Clear() makes mLink get cleared before
we call ~ThreadLink. This causes a race because Clear() is not
holding the monitor. To work around this, I introduced a new method
PrepareToDestroy() that handles the ThreadLink splitting. Once the
ThreadLinks are split, MessageChannel can clear mLink without a
race.
An alternative approach would be to hold the monitor in Clear()
before mLink is cleared, but then we'd end up acquiring the lock
when we didn't need to in the case where mLink is a ProcessLink.
Differential Revision: https://phabricator.services.mozilla.com/D79185
Emilio Cobos Álvarez
Jed Davis
Simon Giesecke
Jeff Gilbert
Andrew Osmond
Andrew McCreight
David Teller
Cosmin Sabou
Anny Gakhokidze
Narcis Beleuzu
Agi Sferro
Sylvestre Ledru
Tom Prince
Nika Layzell
Mihai Alexandru Michis
Kris Maglione
ssengupta
Kashav Madan
Jean-Yves Avenard
Ricky Stewart
Nathan Froyd
Jim Porter
Brindusan Cristian
Junior Hsu
Andrea Marchesini
Razvan Maries
Daisuke Akatsuka
Aaron Klotz
Butkovits Atila
Honza Bambas
Kartikaya Gupta
Dorel Luca
Stephen A Pohl
Ryan VanderMeulen
Nico Grunbaum