The old output had a single value: "atoms-table". The new output looks like
this:
> 649,904 B (00.39%) -- atoms
> ├──350,256 B (00.21%) -- dynamic
> │ ├──235,056 B (00.14%) ── unshared-buffers
> │ └──115,200 B (00.07%) ── atom-objects
> ├──212,992 B (00.13%) ── table
> └───86,656 B (00.05%) ── static/atom-objects
MozReview-Commit-ID: 924vUmxHAlh
--HG--
extra : rebase_source : 6c977546a69eeee62ebc87e335982e8278217484
Switch the order of the IPC FD argument and the crash FD argument in
e10s calls, because the IPC FD is the primary FD, and the crash FD
should be grouped with the crash annotation FD.
MozReview-Commit-ID: CAVyYAIIBPm
--HG--
extra : rebase_source : 02bf7337fa9a6d1194809c224acb4a2690fd87a3
This also changes a few MOZ_LOG() messages to use the error name
instead of the raw numerical nsresult value.
MozReview-Commit-ID: Jcngd0S9j2z
--HG--
extra : rebase_source : f6e974569d8845211e0b25dabef2c41dda2ca1b6
xpt.py only generates constants for a couple of the cases that
XPTConstValue supports. Eliminating the unused cases reduces the size
of this data structure from 64-bit to 32-bit, which reduces the memory
usage of xpti-working set by about 0.02MB.
MozReview-Commit-ID: 1yQkK28fPkR
--HG--
extra : rebase_source : 9d5ce81cfa213cba203ee9c72d2f7dcc8652bd31
num_additional_types is a uint8_t, so its max value is 255. 1 + 255 is
not greater than 256, so the check will pass, but then
num_additional_types += 1 will overflow in the next line.
What I think happened is that bug 1249174 part 6 introduced a bounds
check on an index (which is ok), but then part 8 repurposed this as a
bounds check on the length.
I noticed this because while writing the next patch I ended up with
if (id->num_additional_types > 255)
and then the compiler warned that the check would never fail.
MozReview-Commit-ID: KqiaOyBjj7v
--HG--
extra : rebase_source : 47b20ad2f5e39b05f467cc5b10041070db7fa774
Various strings, like nsISupports, appear many times in XPT data. This
patch adds a cache so we don't write the same string multiple times.
MozReview-Commit-ID: 6buBrXwHqQz
--HG--
extra : rebase_source : 54dea83a9134710c5600828ab68ef3f935f46afd
The name of this class is wrong, but my next patch will make it
actually cache. This patch should not change the behavior.
MozReview-Commit-ID: CMf6Chkeex1
--HG--
extra : rebase_source : a6d5688124b75aef8ed35f811003cf49b8b4e136
The intention is a little more clear with static_assert, as well as
failing sooner. (The code is probably the same, since the compiler will
optimize out the checks as dead code, but meh.)
Reading nsIIDs to binary streams requires 1 + 1 + 1 + 8 calls to Read
for the underlying stream. With the assumption that reading to the
underlying stream for a binary stream is relatively expensive, we should
be able to do better by reading the byte array in an nsIID in a single
Read() request. The same logic applies to writing nsIIDs. Performing a
single operation here should not change the actual bytes read or
written. Performing a single operation also has the virtue of
performing fewer error checks and whatnot.
These are C++ files now. This makes it so the highlighting works if
you use classes, etc.
Also, add Vim modelines.
MozReview-Commit-ID: 6fIkiTDnemt
--HG--
extra : rebase_source : 6232f6bbcf7e19763bbb6ac2cc03290eddb5e608
Without this patch, it's impossible for clients to move a reference into an
nsInterfaceHashtable. That causes at least one extra addref/release pair when
they otherwise could. With this patch, a client can do `hashTable.Put(key,
comptr.forget());` to avoid the additional refcounting.
MozReview-Commit-ID: Ghm7n41ziZp
--HG--
extra : rebase_source : a3e842bf9dfe202134c58e447ecf4fa79851c076
This adds some assertions to make the intended usage of LogModuleManager::Init
more clear.
--HG--
extra : rebase_source : c61e1736cedfbeaa96951ba40cdc954bbc0094d5
These methods will be used in subsequent patches.
MozReview-Commit-ID: EqCpRbn2Y5Y
--HG--
extra : rebase_source : 4b6c2388acb31490a981ca08ba34d4e69c09eddf
The change to RootAccessible.cpp fixes an obvious bug introduced in bug 741707.
The visibility changes in gfx/thebes are because NS_DECL_ISUPPORTS has a
trailing "public:" that those classes were relying on to have public
constructors.
MozReview-Commit-ID: IeB8KIJCGhU
This macro is identical to NS_INTERFACE_MAP_END and encourages the
reader to think that there's something extra-special threadsafe about QI
implementations that use the macro, when in reality there's nothing of
the sort.
Now that this file is all C++, we don't need to duplicate it.
MozReview-Commit-ID: 8nlcGLMnuzV
--HG--
extra : rebase_source : 3fcc2ccd05547de4388f917588d81135b6eb57a8
These are nominally in C, but I don't see any reason for that, given
that we no longer have external consumers. I got rid of "typedef
struct Foo Foo" at the same time.
Also replace a tab I noticed in the definnition of XPT_ANN_LAST.
MozReview-Commit-ID: CFgfiWmuo6r
--HG--
extra : rebase_source : 0bd79ef3055fe1b68a2ec6eaa6eebd0f7e52f730
We don't export these any more, so I don't think there's a reason to
mark them extern.
MozReview-Commit-ID: GbkF7HdRUT6
--HG--
extra : rebase_source : 52e4b72d14bc14d5cfeca110ed4842f2facf356e
These macros haven't done anything since 2006, so get rid of them.
MozReview-Commit-ID: GOakDBIt1Mf
--HG--
extra : rebase_source : 9b0ba6ce42e75aab63c5f63681b37cafe15a367f
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
This adds a fallible version of |NS_UnescapeURL| that can be used to
gracefully handle allocation failures when the string needs to be unescaped.
--HG--
extra : rebase_source : 8d10ca98fb372afe8219d744b147703254e02830
The documentation indicates nsTStringTuple is intended for internal use only
and is designed to be only be used as a temporary. This makes that fact
explicit by annotating the class for static analysis.
--HG--
extra : rebase_source : 737481fb39355c456cf1bbf17b887e35d692c4df
This removes nsSubstringTuple.h and nsSubstringTuple.cpp in favor of
nsTSubstringTuple.
--HG--
extra : rebase_source : 4539b7cccd7a6837ca695782200a2e8d19b8436a
Otherwise, we might enter JS, decide to GC, and deadlock because we were
trying to dispatch tasks to the main thread's event queue while holding
the lock for the event queue.
This enables having a const nsMainThreadPtrHandle<T> member which we want to
ensure doesn't get assigned to, but whose (the `T`'s) non-const methods are
still usable on main thread. Similar to how RefPtr<T> works.
MozReview-Commit-ID: 8CG0MwIZmLc
--HG--
extra : rebase_source : f0e897d3bf4f9a4d752e964ef63de73a9e710752
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This patch adds a new environment variable XPCOM_MEM_LOG_JS_STACK that
changes XPCOM leakchecking to record a JS stack for all objects, in
addition to a C++ stack. This is useful when a C++ object is being
leaked due to JS. The JS stack will be printed if the object leaks, if
it is used in combination with XPCOM_MEM_BLOAT_LOG=1 and
XPCOM_MEM_LOG_CLASSES=nsFoo, if nsFoo is the class of interest.
This patch moves a few XPConnect functions for recording the stack
into xpcpublic.h so they can be called from nsTraceRefcnt.cpp.
MozReview-Commit-ID: FX2QVCSXz4f
--HG--
extra : rebase_source : 5bd4e341072f4cf7d3be774b63d2107479fe9985
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
Currently nsIThreadManager::spinEventLoopUntil doesn't monitor the shutting
down. Firefox shutting down can be blocked by a 'broken' use of
nsIThreadManager::spinEventLoopUntil.
nsIThreadManager::spinEventLoopUntilOrShutdown should be used instead.
The FunctionBroker actors allow the NPAPI process (child) to run methods on the main process (parent). Both the parent and the child run dedicated threads for this task -- this is a top-level protocol.
This removes the need for the content process to have permissions to create new
files on macOS, allowing more aggressive sandboxing.
MozReview-Commit-ID: 8agL5jwxDSL
--HG--
extra : rebase_source : 17ebcef3e9d24f3d4e7515e3fae95e65cef76a79
This removes the need for the content process to have permissions to create new
files on macOS, allowing more aggressive sandboxing.
MozReview-Commit-ID: 8agL5jwxDSL
--HG--
extra : rebase_source : 215577cd5ced3994a4c3345377b3feedea07e886
This method is used to replace some GetNativePath usage for logging.
MozReview-Commit-ID: 9nWf2r4oviA
--HG--
extra : rebase_source : b58e45ab38621179cd802979131fdddbfe65079e
extra : intermediate-source : b4ded2247082f98fe18eb640c5fafeb9bc107ac0
extra : source : 21a82c1faeffc7c0d7b3a5ef0ae4c5243c81a586
This method is used by some subsequent patches when unique opaque identifiers are necessary.
MozReview-Commit-ID: AreqK4MHdJP
--HG--
extra : rebase_source : d5b85c2c9212618f54a6ac2f5199651b01c99510
extra : intermediate-source : 67c3c7a1012b9fdd628928bec61472c6ce580616
extra : source : c9a67330c600dbe454fd2ce5025247171e0c0e22
Currently only |value_type| is implemented.
MozReview-Commit-ID: 1mejzvkuako
--HG--
extra : rebase_source : 69e08073adbb9a866db26e515702a0659ece0a70
extra : intermediate-source : 3696381ddfdc19ab2f901ca4247e1cb4efb27731
extra : source : 35d760da1d73dd51614f434c26e5ce80ff690829
This patch adjusts tools/fuzzing/ in such a way that the relevant parts can be
reused in the JS engine. Changes in detail include:
* Various JS_STANDALONE checks to exclude parts that cannot be included in
those builds.
* Turn LibFuzzerRegistry and LibFuzzerRunner into generic FuzzerRegistry and
FuzzerRunner classes and use them for AFL as well. Previously, AFL was
piggy-backing on gtests which was kind of an ugly solution anyway (besides
that it can't work in JS). Now more code like registry and harness is
shared between the two and they follow almost the same call paths and entry
points. AFL macros in FuzzingInterface have been rewritten accordingly.
This also required name changes in various places. Furthermore, this unifies
the way, the fuzzing target is selected, using the FUZZER environment
variable rather than LIBFUZZER (using LIBFUZZER in browser builds will give
you a deprecation warning because I know some people are using this already
and need time to switch). Previously, AFL target had to be selected using
GTEST_FILTER, so this is also much better now.
* I had to split up FuzzingInterface* such that the STREAM parts are in a
separate set of files FuzzingInterfaceStream* because they use nsStringStream
which is not allowed to be included into the JS engine even in a full browser
build (error: "Using XPCOM strings is limited to code linked into libxul.").
I also had to pull FuzzingInterface.cpp (the RAW part only) into the header
and make it static because otherwise, would have to make not only separate
files but also separate libraries to statically link to the JS engine, which
seemed overkill for a single small function. The streaming equivalent of the
function is still in a cpp file.
* LibFuzzerRegister functions are now unique by appending the module name to
avoid redefinition errors.
MozReview-Commit-ID: 44zWCdglnHr
--HG--
extra : rebase_source : fe07c557032fd33257eb701190becfaf85ab79d0
This patch adjusts tools/fuzzing/ in such a way that the relevant parts can be
reused in the JS engine. Changes in detail include:
* Various JS_STANDALONE checks to exclude parts that cannot be included in
those builds.
* Turn LibFuzzerRegistry and LibFuzzerRunner into generic FuzzerRegistry and
FuzzerRunner classes and use them for AFL as well. Previously, AFL was
piggy-backing on gtests which was kind of an ugly solution anyway (besides
that it can't work in JS). Now more code like registry and harness is
shared between the two and they follow almost the same call paths and entry
points. AFL macros in FuzzingInterface have been rewritten accordingly.
This also required name changes in various places. Furthermore, this unifies
the way, the fuzzing target is selected, using the FUZZER environment
variable rather than LIBFUZZER (using LIBFUZZER in browser builds will give
you a deprecation warning because I know some people are using this already
and need time to switch). Previously, AFL target had to be selected using
GTEST_FILTER, so this is also much better now.
* I had to split up FuzzingInterface* such that the STREAM parts are in a
separate set of files FuzzingInterfaceStream* because they use nsStringStream
which is not allowed to be included into the JS engine even in a full browser
build (error: "Using XPCOM strings is limited to code linked into libxul.").
I also had to pull FuzzingInterface.cpp (the RAW part only) into the header
and make it static because otherwise, would have to make not only separate
files but also separate libraries to statically link to the JS engine, which
seemed overkill for a single small function. The streaming equivalent of the
function is still in a cpp file.
* LibFuzzerRegister functions are now unique by appending the module name to
avoid redefinition errors.
MozReview-Commit-ID: 44zWCdglnHr
--HG--
rename : tools/fuzzing/libfuzzer/harness/LibFuzzerRunner.cpp => tools/fuzzing/interface/harness/FuzzerRunner.cpp
rename : tools/fuzzing/libfuzzer/harness/LibFuzzerRunner.h => tools/fuzzing/interface/harness/FuzzerRunner.h
rename : tools/fuzzing/libfuzzer/harness/LibFuzzerTestHarness.h => tools/fuzzing/interface/harness/FuzzerTestHarness.h
rename : tools/fuzzing/libfuzzer/harness/moz.build => tools/fuzzing/interface/harness/moz.build
rename : tools/fuzzing/libfuzzer/harness/LibFuzzerRegistry.cpp => tools/fuzzing/registry/FuzzerRegistry.cpp
rename : tools/fuzzing/libfuzzer/harness/LibFuzzerRegistry.h => tools/fuzzing/registry/FuzzerRegistry.h
extra : rebase_source : 7d0511ca0591dbf4d099376011402e063a79ee3b
Historically, PSM has handled tracking NSS resources, releasing them, and
shutting down NSS in a coordinated manner (i.e. preventing races,
use-after-frees, etc.). This approach has proved intractable. This patch
introduces a new approach: have XPCOM shut down NSS after all threads have been
joined and the component manager has been shut down (and so there shouldn't be
any XPCOM objects holding NSS resources).
Note that this patch only attempts to determine if this approach will work. If
it does, we will have to go through alter and remove the remnants of the old
approach (i.e. nsNSSShutDownPreventionLock and related machinery). This will be
done in bug 1421084.
MozReview-Commit-ID: LjgEl1UZqkC
--HG--
extra : rebase_source : 2182e60d04e89a91278d5ee91610f8f37d99a9c9