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
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
The current IPC::Message constructor takes a large number of arguments,
three of which--the nesting level, the priority, and the
compression--are almost always constant by virtue of the vast majority
of Message construction being done by auto-generated IPDL code. But
then we take these constant values into the Message constructor, we
check them for various values, and then based on those values, we
perform a bunch of bitfield operations to store flags based on those
values. This is wasted work.
Furthermore, for replies to IPDL messages, we'll construct a Message
object, and then call mutating setters on the Message object that will
perform even more bitfield manipulations. Again, these operations are
performing tasks at runtime that are the same every single time, and use
information we already have at compile time.
The impact of these extra operations is not large, maybe 15-30K of extra
code, depending on platform. Nonetheless, we can easily make them go
away, and make everything cleaner to boot.
This patch adds a HeaderFlags class that encapsulates all the knowledge
about the various kinds of flags Message needs to know about. We can
construct HeaderFlags objects with strongly-typed enum arguments for the
various kinds of flags, and the compiler can take care of folding all of
those flags together into a constant when possible (and it is possible
for all the IPDL-generated code that instantiates Messages). The upshot
is that we do no unnecessary work in the Message constructor itself. We
can also remove various mutating operations on Message, as those
operations were only there to support post-constructor flag twiddling,
which is no longer necessary.
It's important that shmem creation/destruction messages be ordered
correctly with respect to other messages that use shmems. For example,
if we create a shmem with ID 10 and then send a message that
references shmem 10, then the creation message must be handled before
the referencing message. If shmem creation/destruction messages go in
a separate queue from other messages, this ordering may not be
preserved.
Leaving shmem creation/destruction unlabeled will give us the correct
ordering. Eventually, though, we'll need to provide a solution that
doesn't bottleneck the event queue.
MozReview-Commit-ID: 88MrslRrfnh
Using a separate error function will distinguish mismatched sentinels
from other errors, such as array length problems.
MozReview-Commit-ID: Gl8swNhqLns
--HG--
extra : rebase_source : 494759b105086c6c26f3ac53fb644bbf51c12800
Every new PBrowser, whether it's created by the parent or the child, needs
to get a TabGroup assigned to it. That way IPC messages for the PBrowser will
be dispatched to that TabGroup.
For new PBrowsers created by the child, we just create a new TabGroup or reuse
the opener's TabGroup.
For PBrowsers created by the parent, the child needs to intercept the
PBrowserConstructor message and assign a TabGroup immediately. PBrowsers created
by the parent never have an opener so we can always create a new TabGroup.
In both cases, the nsGlobalWindow::TabGroupOuter logic needs to be updated to
read the TabGroup out of the IPC code. Otherwise the DOM and IPC code will get
out of sync about TabGroups.
MozReview-Commit-ID: D5iEdgirfvK
We will use the new type for the generated IPDL message handler
prototype to make sure correct error handling method is called.
MozReview-Commit-ID: AzVbApxFGZ0
This patch moves FatalError to IProtocol. I had to make a few changes.
- I added a ProtocolName() method to find the name of the protocol.
- I gave the two-argument version of FatalError its own name. Otherwise
C++ doesn't like there to be two virtual methods with the same name
in cases where one is overridden and the other isn't (as happens
in IToplevelProtocol).
This moves some of the generated methods in subprotocols that simply defer
to the parent protocol to IProtocol. These methods are still overridden in
the toplevel protocol.
Currently all our protocols inherit from IProtocolManager<IProtocol>. I have
no idea why. This patch switches everything over to IProtocol, without any
templates. I had to move ReadActor to the .cpp file to avoid redefinition
errors.
This patch moves FatalError to IProtocol. I had to make a few changes.
- I added a ProtocolName() method to find the name of the protocol.
- I gave the two-argument version of FatalError its own name. Otherwise
C++ doesn't like there to be two virtual methods with the same name
in cases where one is overridden and the other isn't (as happens
in IToplevelProtocol).
This moves some of the generated methods in subprotocols that simply defer
to the parent protocol to IProtocol. These methods are still overridden in
the toplevel protocol.
Currently all our protocols inherit from IProtocolManager<IProtocol>. I have
no idea why. This patch switches everything over to IProtocol, without any
templates. I had to move ReadActor to the .cpp file to avoid redefinition
errors.