ByteBuf is a new IPDL built in type, so I wrote a very basic test for
it, based on shmem.ipdl. It was added in bug 1379680.
MozReview-Commit-ID: 4tbnljpUqCh
--HG--
extra : rebase_source : 6f423d7d9cf132aba4498be96548684e551b8e2c
Bug 1443954 added some new syntax to using, but I noticed that there
was not very much existing test coverage, so I wrote a new test that
covers all of the possible cases.
MozReview-Commit-ID: JRgHCtXHDLZ
--HG--
extra : rebase_source : caacc05ae5b1de0841f73e5fdba4891bfc0ee4bf
Failing IPDL parser tests require that the error message is specified.
MozReview-Commit-ID: IGNTVAb5r0Q
--HG--
extra : rebase_source : 54e75ae8820f4e9ae2083b1f5382ff4151c8d59e
The IPDL parser now expects a valid message-metadata to be passed in,
even though we don't need it for parser tests. Fix this by creating
and specifying a blank one. This fixes a regression from bug 1348591.
MozReview-Commit-ID: HJ34mqBdUyP
--HG--
extra : rebase_source : d444e5346f40399f1f1cf71b3d86b6dc15a4b731
The ipc/ipdl/test/cxx/ subdirectory is only built when MOZ_IPDL_TESTS
is set, because it needs special code to be built into the
binary. ipdl/ should always be built, because it does not need special
support. This gating is already done in the ipc/ipdl/test/ directory,
so it shouldn't be done in ipc/ipdl/, because this stops us from
building it in a regular build.
MozReview-Commit-ID: Jpp0CeXEenR
--HG--
extra : rebase_source : 3dbb6a5c9b7f6ec8cbe9840bff240a63342ecd49
There are three things we want to be true:
a) If the child sends a large value and the parent can't allocate enough space
for it we use an infallible allocation so the parent dies with an OOM.
b) If a fuzzer generates (huge-length, small-data) we don't try to allocate
huge-length bytes; knowing that the read will fail.
c) No fuzzer-specific branches in the core IPC serialization code.
Finally, this makes (huge-length, small-data) consistent with other cases where
the data is potentially truncated: ReadParam returns false.
MozReview-Commit-ID: 6nDKrw5z4pt
--HG--
extra : rebase_source : 58372d29139e9545a6ed2852c7243affeab6fdb7
We can move this information into ProtocolState and save having two
virtual functions for every protocol. Moving some bits out of the
codegen'd IPC code is a nice bonus, though we keep the strange setup
where toplevel protocols have two mChannel member variables.
ProtocolName() is only used for producing error messages and annotating
crash reports. But examining actual crash reports that would have used
the result of ProtocolName() indicates that we can always tell what the
erroring protocol is due to the stack backtrace. So having this virtual
function around just provides duplicate information, and it takes up too
much space in the vtable besides. Let's get rid of it.
lower.py generates repetitious:
SetManager(...);
Register(...); // Or RegisterID.
SetIPCChannel(...);
calls, which are moderately sized, given that the above call sequence
requires virtual calls in several places. Instead of codegenning this
sequence, let's consolidate the sequence into IProtocol and change the
code generator to call into the consolidated function instead.
This function is only overriden in two places, both of which go away
after early beta is done. We shouldn't be paying for its vtable entry
after that point.
The reasoning here is the same as for the protocol register/lookup
functions: these functions are all basic functionality that should not
be overriden by subclasses.
This functionality is base functionality for top-level and non-toplevel
protocols; nobody overrides this stuff, so it's safe to move into
ProtocolState.
IProtocol, which is inherited by every generated IPDL protocol and every
concrete protocol implementation in-tree, has a number of virtual
methods that are only relevant when distinguishing between top-level
protocols (IToplevelProtocol) and managed protocols (everything else).
These virtual methods require pointers in every protocol's vtable, which
is wasteful, and it's also somewhat confusing that many methods exist
but don't really need to be overridable in any useful way.
Let's clean this up, by creating a ProtocolState class to hold methods
that solely differ between top-level protocols and everything else.
This commit does that work and moves Shmem-related methods into this
class as a proof that this can be done in a reasonable way.
This function is just pure bloat when it gets inlined, and it will
disappear on non-Nightly builds anyway. Make it MOZ_NEVER_INLINE so our
size statistics on Nightly are somewhat more reflective of our size
statistics on Release.
This replaces using file_util to open and unlink temporary files
(/dev/shm on Linux, $TMPDIR or /tmp otherwise) with the POSIX shm_open
API, or ashmem on Android (which doesn't implement shm_open).
glibc maps shm_open/shm_unlink to open and unlink in /dev/shm (as does
musl libc), so the Linux situation is mostly unchanged except we aren't
duplicating code from system libraries. Other OSes may (and some do)
use more efficient implementations than temporary files.
FreeBSD's SHM_ANON extension is used if available. Sadly, it's not
standard; it would make this patch much simpler if it were.
This patch changes the shm file names; they now start with "org.mozilla"
instead of "org.chromium" because the original Chromium code is mostly
gone at this point. When running as a Snap package, the required
filename prefix is added; other container/sandbox environments using
AppArmor to restrict the allowed filenames may need to be adjusted.
The shm names now include the creating process's pid, to allow
using sandboxing to prevent interfering with shm belonging to other
applications or other processes within the same browser instance.
MozReview-Commit-ID: 7PirIlcblh4
--HG--
extra : rebase_source : 550a0ab013429c29a57bde5c0e4593d9b426da8e
I've also manually verified that no other references to HANDLE_EINTR are
wrapping a close() in any less syntactically obvious way.
MozReview-Commit-ID: 3KkBwFIhEIq
--HG--
extra : rebase_source : 4e79a70b3be22a7721b6f85b19ee5a31c98df456
This is based on the current security/sandbox/chromium version of eintr_wrapper.h,
taken from upstream commit 937db09514e061d7983e90e0c448cfa61680f605.
I've edited it to remove some things that aren't relevant to us: the
debug-mode loop limit in HANDLE_EINTR, because we don't seem to be
having the problem it's meant to fix and it risks regressions, and
references to Fuchsia, which we don't (yet) support. I also kept the
original include guards (the file path has changed upstream).
What this patch *does* do is add IGNORE_EINTR and modernize the C++
slightly (using decltype instead of nonstandard typeof).
MozReview-Commit-ID: BO4uQL9jUtf
--HG--
extra : rebase_source : ab3343c6d93e0ce753859217a55af131a0c4ea68
This patch was reviewed in parts, however the intermediate states would not build:
Bug 1443954 - Part 3A: Strip pointers from the argument to WriteParam and WriteIPDLParam before selecting the ParamTraits impl, r=froydnj
Bug 1443954 - Part 3B: Move nsIAlertNotification serialization to the refcounted system, r=bz
Bug 1443954 - Part 3C: Move geolocation serialization to the refcounted system, r=bz
Bug 1443954 - Part 3D: Move nsIInputStream serialization to the refcounted system, r=baku
Bug 1443954 - Part 3E: Move BlobImpl serialization to the refcounted system, r=baku
Bug 1443954 - Part 3F: Correctly implement ParamTraits for actors after the ParamTraits changes, r=froydnj
We want to spin for faster response, but we only want to spin for a very short time.
If we're waiting for a while, we don't want to be burning CPU for the entire time.
Therefore, only spin for 30 ms, then fall back to waiting on an event.
MozReview-Commit-ID: ErAIwpsIqYz
--HG--
extra : rebase_source : b6ac024adb7853456fd06c4385cf32184c8aeca2
I missed this one in bug 1431404.
This condition is rare and does indicate a problem which breaks accessibility.
However, we aren't getting any closer to diagnosing this as a result of this crash, so it causes user pain without any gain to us.
MozReview-Commit-ID: GncQGeZckrV
--HG--
extra : rebase_source : b6670005d53bc6d0009f0b8b142c2ab837b7d2e7
