The WARN_UNUSED_RESULT macro is defined in multiple Google header files in ipc/chromium and webrtc. Copy the WARN_UNUSED_RESULT definition from the latest security/sandbox/chromium/base/compiler_specific.h to our ipc/chromium code. Also remove the ALLOW_UNUSED macro definition because it is no longer defined in the latest compiler_specific.h and is not used anywhere.
Warning: -Wmacro-redefined in ipc/chromium/src/base/compiler_specific.h: 'WARN_UNUSED_RESULT' macro redefined
ipc/chromium/src/base/compiler_specific.h:73:9: warning: 'WARN_UNUSED_RESULT' macro redefined [-Wmacro-redefined]
#define WARN_UNUSED_RESULT __attribute__((warn_unused_result))
media/webrtc/trunk/webrtc/typedefs.h:152:9: note: previous definition is here
#define WARN_UNUSED_RESULT __attribute__ ((__warn_unused_result__))
MozReview-Commit-ID: EUIlXGKLhDL
--HG--
extra : rebase_source : 4c584dfa2243514aef0357ff919d1cba48bd8b86
Assigns the preference security.sandbox.logging.enabled and the environment variable MOZ_SANDBOX_LOGGING to control whether or not sandbox violations are logged. The pref defaults to true. On Linux, only the environment variable is considered.
--HG--
extra : rebase_source : f67870a74795228548b290aec32d08552c068874
WINVER=0x0601 implies PSAPI_VERSION=2. We should not mix PSAPI_VERSION.
MozReview-Commit-ID: Ckxel4JNW2x
--HG--
extra : rebase_source : 932c67a3cae063fe4b0c5fec9048e67ce6286ad3
This just wraps all the XRE method calls to go through the Bootstrap API
instead of relying on the XPCOM glue methods.
--HG--
extra : rebase_source : eccbe18b9b21ca1ab6c403515ffd60f0a9174d9c
We want to avoid calls to XPCOM glue functions, in order to remove them
later on.
--HG--
extra : rebase_source : 505a6f8936339fcf23fba3bbd94cf4dfb22ac761
This folder only contains B2G specific code, which we can now remove from m-c.
Moreover, it is the last consumer of the Scoped.h NSS types provided by
ScopedNSSTypes.h, so removing the folder makes getting rid of Scoped.h easier.
MozReview-Commit-ID: CawbEv1d4vQ
--HG--
extra : rebase_source : b546e4682583aeffcb1b8609f017f58511473ecb
Currently, ipc/chromium detects sparc64 by checking whether
__sparc64__ is defined. However, this definition is used on BSD
targets only. Linux targets define both __sparc__ and __arch64__
on sparc64. Since this also works on BSD, rather use __sparc__
and __arch64__ instead of __sparc64__ to detect sparc64 targets.
This is gnarly IPDL code, but the generated code is probably easier to
review. Before when sending a sync message, we had:
bool sendok__ = (GetIPCChannel())->Send(msg__, (&(reply__)));
if ((!(sendok__))) {
return false;
}
Now, we have:
bool sendok__;
{
GeckoProfilerTracingRAII syncIPCTracer(
"IPC",
"PJavaScript::Msg_PreventExtensions");
sendok__ = (GetIPCChannel())->Send(msg__, (&(reply__)));
}
if ((!(sendok__))) {
return false;
}
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
CreateThreadAttributeList warns:
// Note that the pointer to the HANDLE array ends up embedded in the result of
// this function and must stay alive until FreeThreadAttributeList is called,
// hence it is passed in so the owner is the caller of this function.
but the caller was passing a |handlesToInherit| that was declared inside a block scope that ends before we're finished using lpAttributeList.
This happened to work on MSVC but leads to badness under clang-cl.
+ Bonus fix for a sometimes-uninitialized warning in CreateThreadAttributeList.
MozReview-Commit-ID: 6uu3ICjfj5k
--HG--
extra : rebase_source : 45fd2e4084c80ab60bcf7bee8e1575b40b5b3283
The uses of state() in TestHangs and TestStackHooks only have two
states, depending on how many times the method has been called.
Two uses of state() have to be fixed in TestLatency. Each waits for 5
messages, then resets the state and sends replies.
MozReview-Commit-ID: 7Glj7wbl1ni
--HG--
extra : rebase_source : 55a88a9b31b2effc8af5629262a5f4d34987ba40
The parent process crashes if it gets a bad message from the child,
but that makes it hard to test. This patch overrides the fatal error
handling method and uses the old behavior, that kills the child.
I copied the code to kill the child from TestHangs.
MozReview-Commit-ID: 3YgqaCgHGI0
--HG--
extra : rebase_source : cbecee2742014e969c641b89833cff5f46b99a33
Bill said it is okay to declare interrupt parent-to-child messages now.
MozReview-Commit-ID: 5Ma6pfkUZmt
--HG--
extra : rebase_source : 68fd3f51a9154136003871425762816593d66139
managerNoCtor.ipdl: Add a message so that parsing doesn't just fail
immediately with a syntax error.
shmem_access_union.ipdl: Remove this test, which involves the
semi-removed ACL feature for shmem.
oldIncludesyntax.ipdl: To be safe, make the protocol more valid by
adding a message.
multimanNonexistentMgrs.ipdl: Make the name of the protocol match the
name of the file.
MozReview-Commit-ID: 9zx5fmAWIIc
--HG--
extra : rebase_source : a5b9b9f19bc0329a06ca4ff8be3ef4b879054dd9
Change message annotations from "rpc" to "intr" to match the current
name, and similarly rename the protocols and the files.
MozReview-Commit-ID: Dd9ikvAHMnV
--HG--
extra : rebase_source : 0b2d57ca2c4405319f4ecd6ba2f633128355b381
If qname has no quals, then fullname would be None, which breaks the
string concatenation in parentEndpointDecl and childEndpointDecl, even
if no endpoints are declared. This patch uses the short name if there
are no quals, while preserving the behavior that we want to pass None
into declare for fullname.
MozReview-Commit-ID: 9nuO8GWhBRH
--HG--
extra : rebase_source : df7e8b80d06b5cf1d4905624c0a3c4eac6703612
This patch fixes multipleUsingCxxTypes.ipdl. This is a regression from
bug 918651.
MozReview-Commit-ID: 3ByBvp6FZUe
--HG--
extra : rebase_source : 8038d8662360a8f12e571716eb7c59d2b3754508
As of bug 1240871 these are no longer optional.
MozReview-Commit-ID: 2r2uxJP9dDr
--HG--
extra : rebase_source : 6ca55ae336a7c7d37764b657333e331f3b6158c9
If this code were still used, the last patch would have broken it, so
this seems like a good time to remove it, rather than leave known broken
dead code in the tree.
MozReview-Commit-ID: HvCFm7Ndhku
--HG--
extra : rebase_source : 5bc7101a031548a4c6dbe3f417e9059e448b0f9a
The bug referred to in the comment was fixed 6 years ago.
The includes in cgen.py are unused.
--HG--
extra : rebase_source : f4521112ee3f2280836ac7030b25ddcba2321eda
This patch removes all user-specified state machine support from the
IPDL parser, then deletes all of the code related to it from the AST,
type checking, and code generation. The default state machine code
relating to tracking whether the protocol is dead or not will still be
generated. In fact, this patch should not change the code that is
generated for any protocol that does not use the custom state machine
syntax.
MozReview-Commit-ID: 1fABHR3zJx
--HG--
extra : rebase_source : a2c6655e767741eb7d697e55548c2409a4bdff12
The state machine stuff provides a decent compact overview of where
races are supposed to happen, so I just commented them out.
MozReview-Commit-ID: 1K5mw2kyXWb
--HG--
extra : rebase_source : db3fea5e80c47e04c103b1231077bd9b2c62c4d4
With the removal of state machines, the state() method is no longer
supported, so these assertions must be removed.
MozReview-Commit-ID: 4HV8cQqowlp
--HG--
extra : rebase_source : 512c740e7a7de8904b237d745cddea82dc82a603
The other fields, spec, array, and nullable, are set in some places.
Also remove a dead chunk of code with a FIXME that refers to a bug
that was WONTFIXed in 2010.
--HG--
extra : rebase_source : 184d001a1233e9c035af070bc920c8cbeabc27cc
MessageId has the production "'~' ID", but if you use it, it produces
an error. This error was added in 2009, in bug 525342. I doubt anybody
expects it to work any more, so it should just be a regular parse
error. This is the only usage of the literal ~ so it can now be
removed from there.
MozReview-Commit-ID: AivlLE8Nubv
--HG--
extra : rebase_source : 66f76d1528f0bcf624af97b9437834874e537eb8
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
The IPDL parser handles include statements by using a stack of
parsers. If an inner parser encounters a parsing error, it will print
out an error message, which is maybe okay, but then it makes two
mistakes:
1. It does not pop the current parser off of the parser stack. This
means that the file that included the syntactically invalid file will
be parsed as though it were the invalid file. In bkelly's case, an
.ipdl file included an invalid .ipdlh file, so he got a bizarre error
message about how you can't define a protocol in a header, because the
parser was treating the protocol in the .ipdl file as though it were
in the .ipdlh file. I fixed this by using a "finally" clause to pop
the parser stack, ensuring that it is correct even in case of error.
2. A parse error in the include should cause the entire parse to fail,
but instead it will keep going. inc.tu will get set to None, which
eventually causes an error later in type checking, when it attempts to
examine inc.tu. I fixed this by only catching the parse error where we
invoke the outermost parser. This has the drawback that later errors
in other files will not be reported. An alternate fix would set a
global flag to indicate that a parse error had occured, and somehow
report that to the caller.
I think this bug was introduced in 2009 by commit
cb8189926a69872c73508fba50830f0d07af341f.
MozReview-Commit-ID: DhbDUO7MXGB
--HG--
extra : rebase_source : cee371cd54ebf575f78aa8b2441afbde8b3c2b8f
Giving '0' (literal zero) to RefPtr is now ambiguous, as both
RefPtr(decltype(nullptr)) and RefPtr(T*) could be used.
In any case, our coding standards mandate the use of 'nullptr' for pointers.
So I'm changing all zeroes into nullptr's where necessary.
MozReview-Commit-ID: A458A4e9for
--HG--
extra : rebase_source : bc4107ce1767329e3dddfe34c55ba79202192e06
Preloading libmozsandbox allows the symbol interpositions used by
sandboxing to be defined there instead of statically linked into the
executable; this patch also does that.
MozReview-Commit-ID: FL1QWLSKA0S
--HG--
rename : security/sandbox/linux/interpose/SandboxHooks.cpp => security/sandbox/linux/SandboxHooks.cpp
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).
Moves OnProcessingError, OnChannelError, OnChannelConnected so that they're
only generated for toplevel protocols. For some reason APZCTreeManagerChild
implemented OnProcessingError. I'm not sure what the intention was there so
I removed it.
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.
This patch stores mManager in IProtocol rather than in each individual
PFoo. It also adds a generic accessor for that field. Note that each
individual protocol still defines a Manager() function that returns
PFooParent or whatever. I tried to get rid of that but it was a lot
of work.
With this change, MessageChannel stores mListener as an IToplevelProtocol
rather than a MessageListener (which isn't really a useful concept on
its own). The MessageListener methods are split out to IProtocol and
IToplevelProtocol. MessageListener gets deleted. Some of the inline
functions in MessageChannel had to be moved to MessageChannel.cpp since
IToplevelProtocol isn't defined in MessageChannel.h.
Currently toplevel protocols inherit from both IProtocolManager<IProtocol>
and IToplevelProtocol. This change makes IToplevelProtocol inherit from
IProtocol, so now toplevel protocols only inherit from
IToplevelProtocol.
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 way they'll continue to be at the beginning of the symbol search
path after mozsandbox returns to being a shared library instead of
statically linked into plugin-container.
--HG--
rename : security/sandbox/linux/SandboxHooks.cpp => security/sandbox/linux/interpose/SandboxHooks.cpp
clang has recently made |x $RELATIONAL_OP 0|, where |x| is a variable of
pointer type, to be an error. On Windows,
GeckoChildProcessHost::mChildProcessHandle is a HANDLE, which is really
just a pointer. So the comparison |> 0| in ~GeckoChildProcessHost is
invalid. Fortunately, we can use an equality comparison here and it
amounts to the same thing.
For every protocol's RemoveManagee method, and every sub-protocol that
protocol manages, we generate:
MOZ_DIAGNOSTIC_ASSERT(mManagedPSubProtcolChild.Contains(actor), "...");
which dumps strings into the binary like:
(mManagedPAsmJSCacheEntryChild).Contains(actor) (actor not managed by this!)
MOZ_RELEASE_ASSERT((mManagedPAsmJSCacheEntryChild).Contains(actor)) (actor not managed by this!)
The linker is capable of merging multiple strings together, but
including the sub-protocol in every assert expression effectively
defeats this linker optimization, resulting in ~40KB of unnecessary
strings.
We can improve this situation by taking a reference to the managee
container, and using that reference in the assertion expression. All
the assertion expressions are identical, and the linker can perform the
expected string merging, for a savings of ~40KB.
HSTS priming changes the order of mixed-content blocking and HSTS
upgrades, and adds a priming request to check if a mixed-content load is
accesible over HTTPS and the server supports upgrading via the
Strict-Transport-Security header.
Every call site that uses AsyncOpen2 passes through the mixed-content
blocker, and has a LoadInfo. If the mixed-content blocker marks the load as
needing HSTS priming, nsHttpChannel will build and send an HSTS priming
request on the same URI with the scheme upgraded to HTTPS. If the server
allows the upgrade, then channel performs an internal redirect to the HTTPS URI,
otherwise use the result of mixed-content blocker to allow or block the
load.
nsISiteSecurityService adds an optional boolean out parameter to
determine if the HSTS state is already cached for negative assertions.
If the host has been probed within the previous 24 hours, no HSTS
priming check will be sent.
MozReview-Commit-ID: ES1JruCtDdX
--HG--
extra : rebase_source : 2ac6c93c49f2862fc0b9e595eb0598cd1ea4bedf