MozReview-Commit-ID: 270iURVhNRu
This patch builds upon the existing DLL services functionality:
1) We add code to obtain the name of the subject from the cert used to sign a
binary (if present). This code is added inside mozglue because in the future
we will be using this code from the DLL blocklist, which is also located
there.
2) We add annotation functionality that registers itself for DLL load events
and updates crash reporter annotations as new libraries are loaded. It also
annotates any existing libraries that are also in memory at the time that the
CertAnnotator is first instantiated. This all happens off main thread, with
the exception of actually making the annotation when in a child process.
--HG--
extra : rebase_source : e032ee8c4cf71e5225b51797443764549f4bbe56
For consistency with when MOZ_SOURCE_CHANGESET is set, and because while
slim, there is a chance of conflict with short forms that don't exist
with the full form that could bite us in the long run.
--HG--
extra : rebase_source : fd7057ec58c6267f3f971a96fdf2854f2cd3d89b
Fix several problems when building Breakpad with new NDK unified
headers.
- Unified headers define its own tgkill wrapper, so rename our own
wrapper to __tgkill.
- Unified headers define user_fpxregs_struct for all API levels, so
don't redefine it.
- Only the target sources under google-breakpad/src/common/linux should
use custom Android headers, so change the includes line in moz.build to
use OS_INCLUDES.
MozReview-Commit-ID: HGnUMu5vDUM
--HG--
extra : rebase_source : f5c29c9949a48a8376f84dcc676e5f8df886f130
Apply commit afa9c52715db1e4bfaa4b01c9aec40cc249b689b from the Breakpad
upstream to support building with NDK r16.
MozReview-Commit-ID: D6xafYkjhjt
--HG--
extra : rebase_source : 41921455b9cb5351695f6d0257f130ec9121c20a
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 was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
Fix several problems when building Breakpad with new NDK unified
headers.
- Unified headers define its own tgkill wrapper, so rename our own
wrapper to __tgkill.
- Unified headers define user_fpxregs_struct for all API levels, so
don't redefine it.
- Only the target sources under google-breakpad/src/common/linux should
use custom Android headers, so change the includes line in moz.build to
use OS_INCLUDES.
MozReview-Commit-ID: HGnUMu5vDUM
--HG--
extra : rebase_source : 07da575044ca805a3f7f8ba87be8a8c279f17379
Apply commit afa9c52715db1e4bfaa4b01c9aec40cc249b689b from the Breakpad
upstream to support building with NDK r16.
MozReview-Commit-ID: D6xafYkjhjt
--HG--
extra : rebase_source : 92f92d04ab13ffab6e8891ca048679b6749ab1c7
Historically we built all our binaries in directories in the objdir, then
symlinked them into dist/bin. Some binaries needed to be copied instead
so that certain relative path lookups work properly, so we resorted to
sprinkling `NSDISTMODE=copy` around Makefiles.
This change makes it so we build PROGRAMs (not any other sort of targets)
directly in dist/bin instead. We could do the same for our other targets
with a little more work.
There were several places in the tree that were copying built binaries to
some other place and needed fixup to match the new location of binaries.
On Windows pdb files are left in the objdir where the program was
originally linked. symbolstore.py needs to locate the pdb file both to
determine whether it should dump symbols for a binary and also to copy
the pdb file into the symbol package. We fix this by simply looking for
the pdb file in the current working directory if it isn't present next
to the binary, which matches how we invoke symbolstore.py.
MozReview-Commit-ID: 8TOD1uTXD5e
--HG--
extra : rebase_source : 9140be949b206bb595d9188ce7e8357347ecd9a9
This marks **/docs/** as exclusively docs, and code that is autodoc'd as
inclusively docs.
That means that a change that purely modifies documentation files will *only*
run `docs` tasks, while a change that modifies autodoc'd source code will
*additionaly* run `docs` tasks. The tasks do not run by default.
MozReview-Commit-ID: G9tOK0AwtrI
--HG--
extra : rebase_source : 8dd971e5c9b0eb5f47895664a4ea49442f303ecb
extra : source : 0881de9b2b5e36ec37cc866f1d4af109da57a919
This marks **/docs/** as exclusively docs, and code that is autodoc'd as
inclusively docs.
That means that a change that purely modifies documentation files will *only*
run `docs` tasks, while a change that modifies autodoc'd source code will
*additionaly* run `docs` tasks. The tasks do not run by default.
MozReview-Commit-ID: G9tOK0AwtrI
--HG--
extra : rebase_source : 8dd971e5c9b0eb5f47895664a4ea49442f303ecb
extra : source : 0881de9b2b5e36ec37cc866f1d4af109da57a919
This marks **/docs/** as exclusively docs, and code that is autodoc'd as
inclusively docs.
That means that a change that purely modifies documentation files will *only*
run `docs` tasks, while a change that modifies autodoc'd source code will
*additionaly* run `docs` tasks. The tasks do not run by default.
MozReview-Commit-ID: G9tOK0AwtrI
--HG--
extra : rebase_source : 8dd971e5c9b0eb5f47895664a4ea49442f303ecb
extra : source : 0881de9b2b5e36ec37cc866f1d4af109da57a919
This makes heap objects directly referenced from stack objects accessbile when
debugging minidumps with a debugger, with the cost of doubling the size of
minidumps.
MozReview-Commit-ID: 52ox1lFcaAz
The symbol-upload task currently downloads the symbols-full.zip artifact
from the build task and then uploads it to the symbol server. These zip
files can be very large (>1GB) so we spend a lot of time doing that.
Now that we're uploading to Tecken instead of Socorro, we can instead
just send the URL of the artifact to Tecken's upload API and ask it to
fetch that directly:
https://tecken.readthedocs.io/en/latest/upload.html#upload-by-download-url
This should make the symbol upload task a fair bit faster.
MozReview-Commit-ID: 8HcbgrWYT1O
--HG--
extra : rebase_source : 4e8f7a28c956befb3e291e8be4d41a2b6728e5cd
Bug 1256642 introduced magic at the emitter level to determine whether a
binary contains C++ sources and should be linked with the C compiler or
the C++ compiler.
Unfortunately, the Binary() moz.build template always adds C++ OS
libraries on Android (through STLPORT_LIBS), and C++ libraries on Linux
(stdc++compat).
The latter only ends up forcing every Binary() to be linked with the C++
linker, which is unfortunate, but doesn't cause much problems. The
former, however, involving OS libraries, the magic from bug 1256642
doesn't kick in, so we end up trying to link C++ OS libraries with the C
linker. Which ends up failing, because the libraries in STLPORT_LIBS
require -lm, which, while it's added by the C++ compiler when linking,
is not when the linkage is driven by the C compiler.
Because the fallible library, linked to all GeckoBinary()s is a C++
library, we still ended up linking with the C++ compiler on Android, so
this wasn't actually causing any problem... until I tried to remove that
fallible library in bug 1423803.
Anyways, the core problem is that moz.build evaluation is happening too
early to know whether any C++ sources are being linked together, so
there is no way the Binary() template can do the right thing. So this
change moves the logic to the emitter.
This also changes the type of STLPORT_LIBS to a list.
--HG--
extra : rebase_source : a70ddf7a132f94dc10e7e1db94ae80fb8d7a269f
This change makes upload-symbols tasks use run-task and the in-tree lint
image instead of the private upload-symbols image. A prior change changed
the script to get the token it needs from a Taskcluster secret, so it's no
longer necessary to use the private docker image containing the token.
MozReview-Commit-ID: 6QugVB4chE0
--HG--
extra : rebase_source : e13d29c2a88e055247da374cffa9ea153548749d
This change fixes symbol upload to use a token stored in the Taskcluster
secrets service instead of the token stored in the private Docker image.
Additionally, it changes the script to upload symbols to the Tecken staging
server when run on try so that the upload-symbols tasks can be tested on
try now. In the future there are plans to allow try tasks to upload symbols
to a separate storage area on the production Tecken instance.
MozReview-Commit-ID: BeZGiiwuGp8
--HG--
extra : rebase_source : ee4c680410822e94c3001d07242f69378703659f
This removes an unnecessary level of indirection by replacing all
nsStringGlue.h instances with just nsString.h.
--HG--
extra : rebase_source : 340989240af4018f3ebfd92826ae11b0cb46d019
This includes tests that cover both regular CFI stack walking as well as
pathological corner cases.
MozReview-Commit-ID: GDARnPSemyu
--HG--
extra : source : 1b65c0b41ac31f3645b2318b47072a1100c13183
We want symbolstore.py to fail, preferably loudly, if we can't find the
necessary tools, and throwing away errors here runs counter to that
goal. Dumper is a base class for Dumper_Win32, where we probably don't
have file(1), but Dumper_Win32 shouldn't be calling RunFileCommand.
This removes dead code using headlessClient and lastRunCrashID in crash
reporting. headlessClient is unconditional now. nsIXULRuntime.lastRunCrashID
is not used anymore so remove code for implementing it.
MozReview-Commit-ID: AU4bUeIx3O0
At present it is difficult to determine whether a crash ping is from a
shutdownkill or not. By including ipc_channel_error we will be able to figure
that out.
We also as a bonus get additional insight into ipc channel error types that
lead to crashes.
MozReview-Commit-ID: FepLsSS2tAI
--HG--
extra : rebase_source : 8c17bdd63f7fadb9829df63fe50c044a020b183e
This includes tests that cover both regular CFI stack walking as well as
pathological corner cases.
MozReview-Commit-ID: GDARnPSemyu
--HG--
extra : rebase_source : 99920e03174824020e4b80269c44f34b93b0364a
extra : source : 0560939928bb0f2fe019fa800fe8ee7663db4b8f
memory.h conflicts with a system header, so we have workarounds to
change include paths to work around this.
This is mostly a cherry-pick of this upstream commit:
8bb3d55af7
..but the patch was applied separately to toolkit/crashreporter/google-breakpad
and toolkit/crashreporter/breakpad-client since we've forked the latter,
and there's also one other fixup of a source file included.
MozReview-Commit-ID: HH92HZG7y9n
--HG--
rename : toolkit/crashreporter/google-breakpad/src/common/memory.h => toolkit/crashreporter/google-breakpad/src/common/memory_allocator.h
rename : toolkit/crashreporter/google-breakpad/src/common/memory_unittest.cc => toolkit/crashreporter/google-breakpad/src/common/memory_allocator_unittest.cc
extra : rebase_source : d321475099f000482689d6a6fb8629274ee19a65
extra : histedit_source : d526c27d952dbe73aee87e24701e2a862e1ca3d2
By using the PartialConfigEnvironment, the clients of buildconfig will
depend on config.statusd/ files instead of config.status directly.
Clients can access substs and defines using buildconfig.substs['FOO'] or
buildconfig.defines['BAR'], and then collect file-level dependencies for
make using buildconfig.get_dependencies(). All GENERATED_FILES rules
already make use of this because file_generate.py automatically includes
these dependencies (along with all python modules loaded).
As a result of this commit, re-running configure will no longer cause
the world to be rebuilt. Although config.status is updated, no build
steps use config.status directly and instead depend on values in
config.statusd/, which are written with FileAvoidWrite. Since those
files are not official targets according to the make backend, make won't
try to continually rebuild the backend when those files are out of date.
And since they are FileAvoidWrite, make will only re-run dependent steps
if the actual configure value has changed.
As a result of using JSON to load data from the config.statusd
directory, substs can be unicode (instead of a bare string type).
generate_certdata.py converts the subst manually to a string so the
value can be exported to the environment without issue on Windows.
Additionally, patching the buildconfig.substs dict no longer works, so
the unit-symbolstore.py test was modified to patch the underlying
buildconfig.substs._dict instead.
The other files that needed to be modified make use of all the defines
for the preprocessor. Those that are used during 'mach build' now use
buildconfig.defines['ALLDEFINES'], which maps to a special
FileAvoidWrite file generated for the PartialConfigEnvironment.
MozReview-Commit-ID: 2pJ4s3TVeS8
--HG--
extra : rebase_source : d6bb0208483f9f043e7be1b36907ca13243985f8
Unfortunately this also needs to be kept in Makefile.in to handle
other consumers of INCLUDES while we transition them.
MozReview-Commit-ID: 9OYlu6Jv1XZ
--HG--
extra : rebase_source : 719200501a93e836a03a64b5e1cd950a8f2e696a
The GPU process doesn't have the directory service enabled, so it can't find
a tmp dir to put its .extra files for crash reports. Even if we do enable the
directory service, we still don't get the correct "content process tmp dir" in
the GPU process, because the UUID baked into that folder is passed via the
preferences service, and that isn't initialized in the GPU process either.
Rather than unneccessarily initialize all this stuff in the GPU process just
to get one folder name, we can pass that folder name directly in the argv list.
See comments 12-19 on the bug for further discussion of the various solutions
attempted/explored.
MozReview-Commit-ID: 1sFg27hIe7S
--HG--
extra : rebase_source : 78eb600a58fed45800b9df8303cc4d6898d96ae9
The GPU process doesn't have the directory service enabled, so it can't find
a tmp dir to put its .extra files for crash reports. Even if we do enable the
directory service, we still don't get the correct "content process tmp dir" in
the GPU process, because the UUID baked into that folder is passed via the
preferences service, and that isn't initialized in the GPU process either.
Rather than unneccessarily initialize all this stuff in the GPU process just
to get one folder name, we can pass that folder name directly in the argv list.
See comments 12-19 on the bug for further discussion of the various solutions
attempted/explored.
MozReview-Commit-ID: 1sFg27hIe7S
--HG--
extra : rebase_source : 62ff819c5b03f642cd4b9af7c89c84b790397372
This modifies the minidump analyzer to only output the crashing thread's stack
when invoked. This reduces the raw size of the crash ping by 50% to 70%
depending on the program state when the crash occurred. The minidump-analyzer
can still produce the complete output when invoked with the '--full' option.
MozReview-Commit-ID: 8KaITWqfBKR
--HG--
extra : rebase_source : b71bd47ea1df4fa8fa3da013aef2612a073a42d2
symbolstore.py processes filenames in FILE lines of symbol files to encode
information about the source repository they came from, or to mark
known generated source files. It also reads the dist/include install
manifest so it can map header files from there back to their source locations.
These mappings were broken on Windows because symbolstore.py first passes
filenames into `FixFilenameCase`, which calls `GetFinalPathNameByHandleW`,
which breaks things in two ways:
1) It returns paths with an uppercase drive letter, and source paths from
elsewhere have a lowercase drive letter.
2) It resolves symlinks, and on Taskcluster Windows builds the whole build
is done within a symlinked directory so paths directly from the srcdir
and objdir won't match those canonicalized paths.
This patch adds a `normpath` function to symbolstore.py and moves the
contents of `FixFilenameCase` into it on Windows, and just makes it
an alias for `os.path.normpath` everywhere else. It then uses it everywhere
we deal with paths that will be compared against source file paths from symbol
files so that all paths are canonicalized the same and we can do simple
string matching from there.
Additionally, this patch adds a check to the functional test to verify
that header files from dist/include are correctly mapped to the source
repository. Unfortunately there is still not a test for generated files
because they only appear in the libxul symbol file, and dumping symbols
from libxul is too slow to invoke as part of a unit test.
MozReview-Commit-ID: Dx3z1BZcIvc
--HG--
extra : rebase_source : 80179bbea58a804344a56ef27f438ada76e7fe77
