For some reason, the execution of dbus-launch causes problems after bug
1734934, even though we were executing dbus-launch before. We don't
actually care about valgrind'ing its execution, though, because it's a
system program.
Differential Revision: https://phabricator.services.mozilla.com/D136312
This removes the `@CommandProvider` decorator and the need to implement
mach commands inside subclasses of `MachCommandBase`, and moves all
existing commands out from classes to module level functions.
Differential Revision: https://phabricator.services.mozilla.com/D121512
This removes the `@CommandProvider` decorator and the need to implement
mach commands inside subclasses of `MachCommandBase`, and moves all
existing commands out from classes to module level functions.
Differential Revision: https://phabricator.services.mozilla.com/D121512
This removes the `@CommandProvider` decorator and the need to implement
mach commands inside subclasses of `MachCommandBase`, and moves all
existing commands out from classes to module level functions.
Differential Revision: https://phabricator.services.mozilla.com/D121512
This removes the `@CommandProvider` decorator and the need to implement
mach commands inside subclasses of `MachCommandBase`, and moves all
existing commands out from classes to module level functions.
Differential Revision: https://phabricator.services.mozilla.com/D121512
In practice we already only use SourceSurfaceSharedData as our
rasterized image backing. This means we no longer need to lock the data
to keep it in memory (when we used volatile memory), nor to try to
optimize the surface for the DrawTarget.
Differential Revision: https://phabricator.services.mozilla.com/D124476
Valgrind detects a condition depending on uninitialized value in update_texture_cache. I first ran into this in bug 1716579, and as patch had a large impact on allocation/deallocation workloads with the texture cache, I couldn't decide with confidence that the patch wasn't faulty. In bug 1728618 which causes this error again, however, the patch is much simpler, doesn't interact with unsafe code and does not affect texture cache workloads so it gives me much better confidence that this valgrind error is either a false positive or a miscompilation.
Differential Revision: https://phabricator.services.mozilla.com/D124444
In practice we already only use SourceSurfaceSharedData as our
rasterized image backing. This means we no longer need to lock the data
to keep it in memory (when we used volatile memory), nor to try to
optimize the surface for the DrawTarget.
Differential Revision: https://phabricator.services.mozilla.com/D124476
The purpose of this is to remove as many docstrings from CommandProvider
classes to make the step of moving commands out of classes simpler.
Where possible, the docstring has been moved to or merged with the function.
Differential Revision: https://phabricator.services.mozilla.com/D123288
This step removes all the dependencies of mach commands to
having a MachCommandBase as the `self` by using the `command_context`
argument instead. This also removes any remaining statefulness from those
classes that implement mach commands, ultimately making it easier to move
existing commands out of classes in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D118058
This step removes all the dependencies of mach commands to
having a MachCommandBase as the `self` by using the `command_context`
argument instead. This also removes any remaining statefulness from those
classes that implement mach commands, ultimately making it easier to move
existing commands out of classes in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D118058
It turns out calling gdk_display_close gets us a rematch of bug 1626536,
so remove the call that was added in bug 1718131, and adjust valgrind
suppressions accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D120037
This requires a backport of valgrind to buster instead of jessie (which
we don't need a backport for anymore). Somehow the buster-based
android-build was using the backport for jessie. It now can use the
backport for buster.
We now also need a few extra packages in the valgrind docker image that
used to be installed as a side effect of installing other packages, but
aren't installed automatically anymore, while necessary.
This allows to remove the debian8-amd64-build docker image, now unused.
We add a patch to workaround an issue with rust that was fixed in older
version of valgrind but that resurfaced in a slightly different manner.
Filed upstream as https://bugs.kde.org/show_bug.cgi?id=433641.
Finally, we update the suppressions to account for system changes.
Differential Revision: https://phabricator.services.mozilla.com/D106402
This requires a backport of valgrind to buster instead of jessie (which
we don't need a backport for anymore). Somehow the buster-based
android-build was using the backport for jessie. It now can use the
backport for buster.
We now also need a few extra packages in the valgrind docker image that
used to be installed as a side effect of installing other packages, but
aren't installed automatically anymore, while necessary.
This allows to remove the debian8-amd64-build docker image, now unused.
We add a patch to workaround an issue with rust that was fixed in older
version of valgrind but that resurfaced in a slightly different manner.
Filed upstream as https://bugs.kde.org/show_bug.cgi?id=433641.
Finally, we update the suppressions to account for system changes.
Differential Revision: https://phabricator.services.mozilla.com/D106402
We still need the blocklist to control rollout on Android, but on
desktop, we should be shipping Software WebRender to all users, except
those in safe mode or whom have explicitly disabled WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D117088
There is a valgrind suppression on a generic signature containing the hash of rust types. The hash changes when crate dependencies are updated.
Differential Revision: https://phabricator.services.mozilla.com/D116588
As an intermediate step to allow mach commands as standalone functions, the MachCommandBase
subclass instance that currently corresponds to self has to be made available as a separate
argument (named command_context).
Differential Revision: https://phabricator.services.mozilla.com/D109650
It's a relatively minor one (two keyframes are leaked). I built latest
GTK3 from source and it wasn't reproducible locally. I think our GTK
version on automation might be too old and not have this commit:
10fa786dfa
Or something of that sort.
Differential Revision: https://phabricator.services.mozilla.com/D113948
As an intermediate step to allow mach commands as standalone functions, the MachCommandBase
subclass instance that currently corresponds to self has to be made available as a separate
argument (named command_context).
Differential Revision: https://phabricator.services.mozilla.com/D109650
As an intermediate step to allow mach commands as standalone functions, the MachCommandBase
subclass instance that currently corresponds to self has to be made available as a separate
argument (named command_context).
Differential Revision: https://phabricator.services.mozilla.com/D109650
If we encounter a single error in glxtest, we typically bail immediately
with one liner message. This patch makes it put more effort into
returning what information it is able to, as well as the current error
messages. If certain errors are correlated to specific devices, it would
be useful if we had the information to make the connection.
Differential Revision: https://phabricator.services.mozilla.com/D97861
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Today we don't require that `mach` `CommandProvider`s subclass from any particular parent class and we're very lax about the requirements they must meet. While that's convenient in certain circumstances, it has some unfortunate implications for feature development.
Today the only requirements that we have for `CommandProvider`s are that they have an `__init__()` method that takes either 1 or 2 arguments, the second of which must be called `context` and is populated with the `mach` `CommandContext`. Again, while this flexibility is occasionally convenient, it is limiting. As we add features to `mach`, having a better idea what the shape of our `CommandProvider`s are and how we can instantiate them and use them is increasingly important, and this gives us additional control when having `mach` configure `CommandProvider`s based on data that is only available at the `mach` level. In particular, we plan to leverage this in bugs 985141 and 1654074.
Here we add validation to the `CommandProvider` decorator to ensure all classes inherit from `MachCommandBase`, update all `CommandProvider`s in-tree to inherit from `MachCommandBase`, and update source and test code accordingly.
Follow-up work: we now require (de facto) that the `context` be populated with a `topdir` attribute by the `populate_context_handler` function, since instantiating the `MachCommandBase` requires a `topdir` be provided. This is fine for now in the interest of keeping this patch reasonably sized, but some additional refactoring could make this cleaner.
Differential Revision: https://phabricator.services.mozilla.com/D86255
This has the side effect of not initializing fontconfig before the
valgrind test itself runs, which changes the code path leading to
`FcConfigAddDirList`, which eventually leads to suppressed leaks.
Those leaks are then not discarded because the caller doesn't match what
is in the suppression file anymore, so we remove the caller.
Differential Revision: https://phabricator.services.mozilla.com/D85353
And add suppressions for the new errors that this adds to the valgrind
run. It's not clear if it's a legitimate thing that LLVM does that
valgrind doesn't cope with, like many others, but the fact is running
valgrind on a PGO/LTO build doesn't show these errors, so we're not
actually shipping them anyways (but does show _different_ errors that we
don't see on the build the valgrind jobs do)
Differential Revision: https://phabricator.services.mozilla.com/D81016
