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
