The first two are variants of existing ones, with a slightly different
signature, and tha last one is well known and found in glib-related
suppression files like https://github.com/flatpak/flatpak/blob/master/tests/glib.supp
--HG--
extra : rebase_source : 2a209cc5987405e7ff638bbf69e1b74202b0357e
The MACHTYPE bash variable is an odd thing that returns e.g.
x86_64-redhat-linux-gnu on a CentOS system, but x86_64-pc-linux-gnu
on a Debian system, and possibly something different on other distros.
mach valgrind-test is the only place actually relying on MACHTYPE.
Others rely on information from python modules. Uniformize that, and use
the more generic 'pc' rather than 'redhat'.
--HG--
rename : build/valgrind/i386-redhat-linux-gnu.sup => build/valgrind/i386-pc-linux-gnu.sup
rename : build/valgrind/x86_64-redhat-linux-gnu.sup => build/valgrind/x86_64-pc-linux-gnu.sup
extra : rebase_source : ad94ce69e8094d2b9ddae97a3d261945886c0a61
We believe this is another spurious memcheck error triggered
by code from Rust 1.23.0. See also bug 1394696.
For some reason, this error occurs both with and without
the leading underscore on mangled std::sync::once methods,
so this change matches either with a wildcard.
MozReview-Commit-ID: 4upSAPqAtNA
--HG--
extra : rebase_source : 5f697aaa5e170369f08d385d10c1aac9d8c1e50b
LLVM can optimize code to a form `if B && A` when A is
always false but B is undefined. This triggers a valgrind
memcheck warning since the conditional depends on undefined
data but in practice it can never have side-effects.
Rust 1.20.0 seems to trigger this in the Option code. Since
we believe the transform is correct in these cases and
valgrind is incorrect to warn, we surpress the error.
Thanks to Julian Seward for the analysis and help
writing the suppression entries.
MozReview-Commit-ID: pF1Bmy5PRY
This removes the double-include macro hackery that we use to define two
separate string types (nsAString and nsACString) in favor of a templated
solution.
Annotations for Valgrind and the JS hazard analysis are updated as well as
the rust binding generations for string code.
--HG--
extra : rebase_source : 63ab2c4620cfcd4b764d42d654c82f30f984d016
extra : source : 9115364cd4aa078c49bba7911069f8178e55166f
Using /home/worker is the build directory has a 30% talos performance
loss, because test machines has a /home mount directory.
MozReview-Commit-ID: 554IPMRWgzK
--HG--
extra : rebase_source : 00827d3f6bd705419bc801eb05b543af1ddc274f
This patch:
* Adds a suppression for some leaks in libLLVM-3.6-mesa.so.
* Adds Valgrind flag --keep-debuginfo=yes so that the abovementioned leak
stacks can be symbolised and hence suppressed even after
libLLVM-3.6-mesa.so is unmapped from the process.
* Adds Valgrind flag --expensive-definedness-checks=yes as an attempt to
reduce Memcheck false positives from LLVM and rustc compiled code. This
change is aimed primarily at bug 1365915.
MozReview-Commit-ID: KiOZG2O8wzs
Bug 1338651 was backed out because when building a newer image, there
was a valgrind leak report that couldn't resolve symbols. Further
investigation showed the valgrind package installed had symbols stripped.
We upgrade valgrind version and build it from source with symbols.
We had to build inside the docker image because we need to run
"make install". Using "make dist" to generate a tar ball will also run
"make docs", and it is hard to make it work because of the outdated
texlive package present in CentOS 6.
We also apply a patch [1] to valgrind correctly generate symbols
for unloaded objects.
[1] https://bugs.kde.org/show_bug.cgi?id=79362#c62
MozReview-Commit-ID: 2IhuJY28Ke3
It was used for valgrind buildbot jobs, but those have been gone since
bug 1278611, and the taskcluster jobs use mozharness.
--HG--
extra : rebase_source : b9d39b1515a677d0662c2f13f21d83b953e70054
This additionally changes exit() calls with |return VALUE| so
that we are sure to call the destructors and valgrind doesn't complain.
Moreover, this disables the 'new-profile' ping when Firefox is ran
on valgrind.
MozReview-Commit-ID: BlGE9w6yGCL
--HG--
extra : rebase_source : d21b7404ac8dba6f3664f0f8d375429a0dec0ee4
Valgrind-test's output handler buffers valgrind's output to detect
errors and emit proper messages that are detected by automation log
parsing. When an error is detected, the buffered output is reinjected,
but there was a typo that prevented that from actually happening,
which ate the first lines of stack traces.
This will add more verbosity, with the intent of having the triggered
suppressions be displayed in the form:
"--23983-- used_suppression: 3 Bug 794372 /builds/slave/try-l64-valgrind-0000000000000/src/build/valgrind/cross-architecture.sup:90 suppressed: 20,736 bytes in 648 blocks"
