In order to implement profile-per-install we need a mutable INI parser in early
startup. The current one is implemented in JavaScript and thus not available.
This makes the current read-only C++ INI parser mutable and removes the
JavaScript implementation.
It turns out that the two different implementations of nsIINIParserFactory and
nsIINIParser behaved slightly differently but only in ways that the single test
cared about so I've adjusted things a little to make it work.
The existing C++ implementation did not do validity checks on arguments, this
adds that making empty sections and values illegal.
Differential Revision: https://phabricator.services.mozilla.com/D3851
--HG--
rename : xpcom/tests/unit/test_iniProcessor.js => xpcom/tests/unit/test_iniParser.js
extra : source : 524941c8ed0e048ee51be1bd11082b41428ef490
extra : amend_source : 2de6cef5be97448a41733bedda29d6af34aed27a
This adds support for the DW_AT_ranges attribute when dumping out symbols and
adds basic support for AArch64 (64-bit ARM) on Windows in the minidump
processor.
Differential Revision: https://phabricator.services.mozilla.com/D3443
--HG--
extra : moz-landing-system : lando
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant C++ functions are updated to take a typed enum. JavaScript
calls are unaffected but they will throw if the string argument does not
correspond to one of the known entries in the C++ enum. The existing whitelists
and blacklists of annotations are also generated from the YAML file and all
duplicate code related to them has been consolidated. Once written out to the
.extra file the annotations are converted in string form and are no different
than the existing ones.
All existing annotations have been included in the list (and some obsolete ones
have been removed) and all call sites have been updated including tests where
appropriate.
--HG--
extra : source : 4f6c43f2830701ec5552e08e3f1b06fe6d045860
Summary:
The about:crashes page is being updated (bug 1463515). To facilitate these changes,
this patch changes the about:crashes page to use Fluent for localization instead of the old systems.
This also includes a script to migrate strings from the old .DTD and .properties files
to the new .ftl one.
Test Plan:
1. build Firefox with the changes
2. run Firefox
3. go to the about:crashes page
4. expect nothing to be different
This extension: https://github.com/rhelmer/webext-experiment-crashme can be used to
add local crash reports for verifying the different states of the about:crashes page.
Reviewers: flod, Pike, jchen, snorp
Reviewed By: flod, Pike, jchen, snorp
Subscribers: nalexander, reviewbot
Bug #: 1476034
Differential Revision: https://phabricator.services.mozilla.com/D2225
--HG--
extra : rebase_source : 0ca9516b4df78e735fd03907f2ea324bc72ca893
- In bug 1356382, jsoncpp was moved from toolkit/crashreporter
to toolkit/components
- update-jsoncpp.sh has been moved to the components directory
and updated to match the new directories.
MozReview-Commit-ID: Cl71Dwoyn0N
--HG--
rename : toolkit/crashreporter/update-jsoncpp.sh => toolkit/components/update-jsoncpp.sh
extra : rebase_source : ca8c82b9bfa731e2250642533b68b21cb3ec85f1
Use the fact that a JobIntentService is still a Service to keep most of the
previous implementation and method of starting CrashReportingService.
On 26+ devices it will be called with "start-foreground-service".
This ensures it can be started even from background and the crash reporting
process would work as before but ActivityManager will post an ANR error to
logcat after 5 seconds because we aren't calling Service.startForeground()
(which would mean a user visible notification).
Will use different Job Ids depending on if the app is Firefox Release or
Firefox Beta.
The Job Id will be passed to GeckoThread when first initializing and then be
made available to CrashHandler and nsExceptionHandler.cpp to be sent in the
Intent that starts the CrashReporterService.
MozReview-Commit-ID: GATl6Waa9St
--HG--
extra : amend_source : 70bc130b9411df336181e825ebb3e19bdc5a778c
The new version of breakpad imported in bug 1309172 doesn't demangle
rust symbols at all, contrary to before, where it tried to C++ demangle
them, which worked for many, although far from all. It however has
rust-demangle support as long as it's linked against a copy of the
rust-demangle-capi crate from https://github.com/luser/rust-demangle-capi/
This imports the code from the rust-demangle-capi crate but because of
some build system complications it's not taken as-is:
- it uses rusty-cheddar, which is deprecated, to generate a C header.
- rusty-cheddar depends on syntex_syntax, which now fails to build.
- rust-demangle-capi has crate-type staticlib, which can't be used
as a dependency in a Cargo.toml. For that reason, we can't create
a fake crate that depends on it to have it vendored.
Overall, it's only a few lines of rust, and the C header can be written
manually, so this is what we do here. The created crate is named in a way
specific to dump_syms.
The build system doesn't know how to figure out what system libraries
are required to link rust static libraries, although the rust compiler
has /some/ support to get the information, so we handle that manually.
--HG--
extra : rebase_source : 9f5a9bfe2148d3040e11c7121a88e85a7f2d5c53
This makes one less place where we link code compiled for libxul into a
place that doesn't link mozglue, and is cleaner to boot. We don't need
the BREAKPAD_NO_TERMINATE_THREAD define that breakpad-windows-libxul
defines because we're not including the handler code in the
crashreporter binary.
This will make sure that when running |mach python-test --python 3| locally,
we only run the tests that also run in CI with python 3 (and therefore pass
presumably).
MozReview-Commit-ID: 3OBr9yLSlSq
--HG--
extra : rebase_source : 456340d0ecdddf1078f2b5b4ebb1eddf3813b26a
This includes both the vanilla sources we haven't forked and the client
sources that we have. Client patches were applied manually up to version
69c2c51dd89965d234eec16e3a9353634831916b. The following changes were not
included as they break merging segments corresponding to libxul.so in the
module list:
8915f7be39448d9257b6da3ad0233944d1d9a92a
17ad0c18b179c135fc5a3d2bba199c3fa4276035
94b6309aecaddfcf11672f6cfad9575d68ad3b40
With these changes applied two entries for libxul.so are generated, the second
one is bogus and prevents symbolication from working correctly.
The build system and some of the tools relying on breakpad were also updated
to work with the new version.
--HG--
extra : source : fe4d49307f8890a0c430c257c96f74a9552eeb31
extra : histedit_source : bc84861445bd93856cd0d0c864fd15ad7d9ccc12%2C1efd65797da46e33481afa61a302098780b0f107
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : dd000a05bfc2da40c586644d33ca4508fa5330f6
Add missing mutex acquisition calls to protect crashReporterAPIData_Hash and avoid
races with CrashReporter::AnnotateCrashReport() that cause assertion failures.
MozReview-Commit-ID: 6AzSlMMKV3h
--HG--
extra : rebase_source : 5bf6057587c2dcf615140fde66b80a99372b82bd
Bug 1458161 added a rust OOM handler based on an unstable API that was
removed in 1.27, replaced with something that didn't allow to get the
failed allocation size.
Latest 1.28 nightly (2018-06-13) has
https://github.com/rust-lang/rust/pull/50880,
https://github.com/rust-lang/rust/pull/51264 and
https://github.com/rust-lang/rust/pull/51241 merged, which allow to
hook the OOM handler and get the failed allocation size again.
Because this is still an unstable API, we explicitly depend on strict
versions of rustc. We also explicitly error out if automation builds
end up using a rustc version that doesn't allow us to get the allocation
size for rust OOM, because we don't want that to happen without knowing.
--HG--
extra : rebase_source : 6c097151046d088cf51f4755dd69bde97bb8bd8b
It turns out sometimes (in the LTO+CFI case at least) Assertions.h
will not be present in the opt build, presumably because it was optimized
out.
MozReview-Commit-ID: GB3GIoSdIUK
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
When DW_AT_MIPS_linkage_name doesn't demangle, breakpad currently throws
the symbol completely, but in some cases, there is no DW_AT_name or
DW_AT_abstract_origin to figure out a name, and the raw value from
DW_AT_MIPS_linkage_name is still better than nothing. Fall back to that
in when there is nothing else.
--HG--
extra : rebase_source : bb6a60ddc6e3d825e4da85f7c8a54258800ad9e2
The crash reporter symbol files are the easiest cross-platform way to
find static initializers. While some types of static initializers (e.g.
__attribute__(constructor) functions) don't appear there in a notable
way, the static initializers we do care the most about for tracking do
(static initializers from C++ globals). As a matter of fact, there is
only a difference of 2 compared to the currently reported count of 125
on a linux64 build, so this is a good enough approximation. And allows
us to easily track the count on Android, OSX and Windows builds, which
we currently don't do.
The tricky part is that the symbol files are in
dist/crashreporter-symbols/$lib/$fileid/$lib.sym, and $fileid is hard to
figure out. There is a `fileid` tool in testing/tools, but it is a
target binary, meaning it's not available on cross builds (OSX,
Android).
So the simplest is just to gather the data while creating the symbol
files, which unfortunately requires to go through some hoops to make it
happen for just the files we care about.
--HG--
extra : rebase_source : 458fed1ffd6f9294eefef61f10ff7a284af0d986
