Bug 1547085 - Discard messages sent to dead actors, r=jld
Historically we've failed very loudly when receiving a message which was
destined for an actor which had already been destroyed. This had the
effect of requiring manual teardown for most actors, as work would need
to be done to ensure messages weren't sent when the target actor might
be about to tear itself down.
In addition, due to this teardown work being done outside of IPDL, this
work would have to manually be checked in subactors, and involved the
addition of new flags, such as `mIPCOpen`, in order to track whether IPC
had begun to be shut down, and discard messages manually if it had.
It is an ongoing issue that we occasionally miss places where we need to
discard messages, and it is easy to not remember to perform async
destruction when building a new actor, meaning that extra work is
required to correctly discard messages when the actor is being torn
down. Due to the correct decision, almost all of the time, being to
discard the message, this patch takes the approach of transforming the
crash which was previously performed into a message discard.
The hope is that this will reduce the burden on actor implementors, by
allowing the use of `Send__delete__` without first synchronizing with
the remote actor, as well as reduce unintentional crashes.
Differential Revision: https://phabricator.services.mozilla.com/D28892

7de7d6a0be86d400ee23ca1ac806eb358555b28d: Bug 1514869 - patch 8 - Make the SetCharacterMap message async, and use the unshared gfxCharacterMap in the content process until the shared one is in place. r=jwatt,jld

Bug 1494469 - Removed duplicate IPC::MAX_MESSAGE_SIZE constant r=jld
The maximum size of an IPC message is defined twice; IPC::Channel::kMaximumMessageSize = 256 MiB and IPC::MAX_MESSAGE_SIZE = 65 KiB . The latter one is used for Windows printing and its small size could cause errors.
I removed the small constant, and made changes to the files using it :
- The windows printing file now uses kMaximumMessageSize / 2
- nsWebBrowserPersist uses its old constant
Differential Revision: https://phabricator.services.mozilla.com/D24972

Bug 1541130: Add XRE_GetChildProcBinPathType to nsXULAppAPI.h; r=froydnj,jld on a CLOSED TREE
The binary path type of a particular content process is useful information
outside of IPC. Given that `XRE_EnableSameExecutableForContentProc` already
exists, and given that the binary path type is closely related to
`GeckoProcessType`, I've added a new function, `XRE_GetContentProcBinPathType`.
The mapping of process type to binary type has been moved to the
`GeckoProcessTypes` definitions.
This patch also modifies `ipc::GeckoChildProcessHost` to call into the new
function.
Differential Revision: https://phabricator.services.mozilla.com/D25816

Bug 1541130: Add XRE_GetChildProcBinPathType to nsXULAppAPI.h; r=froydnj,jld
The binary path type of a particular content process is useful information
outside of IPC. Given that `XRE_EnableSameExecutableForContentProc` already
exists, and given that the binary path type is closely related to
`GeckoProcessType`, I've added a new function, `XRE_GetContentProcBinPathType`.
The mapping of process type to binary type has been moved to the
`GeckoProcessTypes` definitions.
This patch also modifies `ipc::GeckoChildProcessHost` to call into the new
function.
Differential Revision: https://phabricator.services.mozilla.com/D25816

656108173cde7bbc6bab7dfee15dea907b0af05a: Bug 1541130: Follow-up: Add more missing parts that had been stripped during rebase; r=froydnj, jld on a CLOSED TREE

Bug 1541130: Add XRE_GetChildProcBinPathType to nsXULAppAPI.h; r=froydnj,jld
The binary path type of a particular content process is useful information
outside of IPC. Given that `XRE_EnableSameExecutableForContentProc` already
exists, and given that the binary path type is closely related to
`GeckoProcessType`, I've added a new function, `XRE_GetContentProcBinPathType`.
The mapping of process type to binary type has been moved to the
`GeckoProcessTypes` definitions.
This patch also modifies `ipc::GeckoChildProcessHost` to call into the new
function.
Differential Revision: https://phabricator.services.mozilla.com/D25816

Bug 1525813 - Ensure ipc::ShmemCreated message serializes shmem size as uint32_t. r=jld
Shmem sizes serialized in an ipc::ShmemCreated message should be sent as an
uint32_t rather than a size_t, as size_t is defined as different sizes in 64
and 32 bit builds. If the size isn't consistent, we won't be able to reliably
send this message between cross architecture processes.
Also, Shmem's have a limit of 32bit for their size anyway:
https://searchfox.org/mozilla-central/rev/e00ea598e52bbb35f8c45abf9c2eade17962bb5e/ipc/glue/Shmem.cpp#127
So this patch should not affect allocations of shmems.
Differential Revision: https://phabricator.services.mozilla.com/D18909

Bug 1509362 - Don't crash when constructing actor during content shutdown, r=jld
When shutting down a content process, we call `Close` on the
`IToplevelProtocol`. This causes the MessageChannel to be `Close`-ed,
which in turn sends a `GOODBYE_MESSAGE`:
https://searchfox.org/mozilla-central/rev/876022232b15425bb9efde189caf747823b39567/ipc/glue/MessageChannel.cpp#2852
This message is intercepted on the I/O thread in the content process,
before any code is informed in content, and used to set the
`mChannelState` property to `ChannelClosing`:
https://searchfox.org/mozilla-central/rev/876022232b15425bb9efde189caf747823b39567/ipc/glue/MessageChannel.cpp#1176
Once this state has been set, which is performed as soon as the
message is received, whether or not other messages have been processed
yet, no messages can be sent back to the parent process. This is
usually what causes the 'Too late to send/recv' message spam in the
console, as we're still trying to send messages at this time.
Usually this is fine - the message send fails, but we gracefully
recover, and the process begins shutting down like normal.
Unfortunately, child actor constructors currently have code
automatically generated in them which causes a process crash if the
send fails. As it's impossible for the main thread to know that the
channel has been closed ahead of time (due to this happening
out-of-band), we can then cause random content process crashes
during shutdown due to actor construction.
Unfortunately, we can't just destroy the actor, as our caller may
(and often do) depend on the actor reference they gave us still being valid
after calling Send*Constructor. Fortunately, if a message send failed, it means
we're in the process of being shut down.
This patch handles this by ignoring ctor send errors, and treating them like
messages which successfully were queued to send, but got lost due to the other
side hanging up. The actor will be gracefully destroyed in DestroySubtree when
its manager is destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D12695

Bug 1509362 - Don't crash when constructing actor during content shutdown, r=jld
When shutting down a content process, we call `Close` on the
`IToplevelProtocol`. This causes the MessageChannel to be `Close`-ed,
which in turn sends a `GOODBYE_MESSAGE`:
https://searchfox.org/mozilla-central/rev/876022232b15425bb9efde189caf747823b39567/ipc/glue/MessageChannel.cpp#2852
This message is intercepted on the I/O thread in the content process,
before any code is informed in content, and used to set the
`mChannelState` property to `ChannelClosing`:
https://searchfox.org/mozilla-central/rev/876022232b15425bb9efde189caf747823b39567/ipc/glue/MessageChannel.cpp#1176
Once this state has been set, which is performed as soon as the
message is received, whether or not other messages have been processed
yet, no messages can be sent back to the parent process. This is
usually what causes the 'Too late to send/recv' message spam in the
console, as we're still trying to send messages at this time.
Usually this is fine - the message send fails, but we gracefully
recover, and the process begins shutting down like normal.
Unfortunately, child actor constructors currently have code
automatically generated in them which causes a process crash if the
send fails. As it's impossible for the main thread to know that the
channel has been closed ahead of time (due to this happening
out-of-band), we can then cause random content process crashes
during shutdown due to actor construction.
Unfortunately, we can't just destroy the actor, as our caller may
(and often do) depend on the actor reference they gave us still being valid
after calling Send*Constructor. Fortunately, if a message send failed, it means
we're in the process of being shut down.
This patch handles this by ignoring ctor send errors, and treating them like
messages which successfully were queued to send, but got lost due to the other
side hanging up. The actor will be gracefully destroyed in DestroySubtree when
its manager is destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D12695

Bug 1509930 - Simplify CycleCollectWithLogsChild's lifetime, r=jld
Previously this actor would call `Send__delete__` in its destructor, meaning
that the lifetime of the actor is a bit hard to follow. This changes the actor
to instead use a separate object for XPCOM, and use refcounting universally.
This should also help with the transition to universally refcounted actors.
Differential Revision: https://phabricator.services.mozilla.com/D12955

Bug 1509362 - Don't crash when constructing actor during content shutdown, r=jld
When shutting down a content process, we call `Close` on the
`IToplevelProtocol`. This causes the MessageChannel to be `Close`-ed,
which in turn sends a `GOODBYE_MESSAGE`:
https://searchfox.org/mozilla-central/rev/876022232b15425bb9efde189caf747823b39567/ipc/glue/MessageChannel.cpp#2852
This message is intercepted on the I/O thread in the content process,
before any code is informed in content, and used to set the
`mChannelState` property to `ChannelClosing`:
https://searchfox.org/mozilla-central/rev/876022232b15425bb9efde189caf747823b39567/ipc/glue/MessageChannel.cpp#1176
Once this state has been set, which is performed as soon as the
message is received, whether or not other messages have been processed
yet, no messages can be sent back to the parent process. This is
usually what causes the 'Too late to send/recv' message spam in the
console, as we're still trying to send messages at this time.
Usually this is fine - the message send fails, but we gracefully
recover, and the process begins shutting down like normal.
Unfortunately, child actor constructors currently have code
automatically generated in them which causes a process crash if the
send fails. As it's impossible for the main thread to know that the
channel has been closed ahead of time (due to this happening
out-of-band), we can then cause random content process crashes
during shutdown due to actor construction.
Unfortunately, we can't just destroy the actor, as our caller may
(and often do) depend on the actor reference they gave us still being valid
after calling Send*Constructor. Fortunately, if a message send failed, it means
we're in the process of being shut down.
This patch handles this by ignoring ctor send errors, and treating them like
messages which successfully were queued to send, but got lost due to the other
side hanging up. The actor will be gracefully destroyed in DestroySubtree when
its manager is destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D12695

Bug 1509930 - Simplify CycleCollectWithLogsChild's lifetime, r=jld
Previously this actor would call `Send__delete__` in its destructor, meaning
that the lifetime of the actor is a bit hard to follow. This changes the actor
to instead use a separate object for XPCOM, and use refcounting universally.
This should also help with the transition to universally refcounted actors.
Differential Revision: https://phabricator.services.mozilla.com/D12955

Bug 1500219: Part 1 - Add ability to send and receive UniquePtr<T> with IPDL (r=jld)
This patch adds the ability to use UniquePtr<T> in IPDL messages if T is serializable. The behavior works as expected -- a UniquePtr in a Send is cleared and is passed by move.
Some design points:
* The UniquePtr identification is done in the parser. This is because the parser immediately normalizes CxxTemplateInst -- an old version of the patch did hacky string-parsing to pull it apart. I, instead, created CxxUniquePtrInst.
* The implementation allows passing to Send... by move or by reference. This is valid UniquePtr API behavior but passing by reference is not really useful in this case (but not harmful). This could probably piggy-back on the "moveonly" IPDL work but that is newer than this work and will require some refactoring.
Differential Revision: https://phabricator.services.mozilla.com/D9143

Bug 1475139 part 2 - Add 'moveonly' qualifier to IPDL using statements. r=jld
I'd like to use a struct over IPDL which is move only. This patch adds a modifier to
usings statements to indicate the C++ type should always be moved, similar to refcounted.
Differential Revision: https://phabricator.services.mozilla.com/D6781

Bug 1495871 - remove chromium atomics code; r=jld
The only consumer of this code was Singleton, which we previously
removed, and everything that this code accomplished can be done more
simply and more foolproof-y by standard constructs these days.