This adds logging to Pacer<T>, which is currently only used by
VideoFrameConverter. It also updates VideoFrameConverter's own logging through a
dedicated macro, and puts both classes' on the MediaPipeline log module.
Differential Revision: https://phabricator.services.mozilla.com/D224701
Note this doesn't block the caller, which helps avoid hanging some tests, but
instead relies on the caller spinning the event loop. The latter typically
happens through WaitFor(RefPtr<MozPromise>).
Differential Revision: https://phabricator.services.mozilla.com/D224699
This is causing problems when loading real world sites in debug builds,
which is hurting automated bug finding, so disable this assertion.
mTrackingScripts look like it is only used to decide when to delay a
load sometimes, so I think it isn't a huge deal if this is inconsistent
sometimes.
Differential Revision: https://phabricator.services.mozilla.com/D224996
This patch fixes an issue where having `skip-if` defined in the test manifests would prevent perfdocs from finding the test even though it exists.
Differential Revision: https://phabricator.services.mozilla.com/D225696
This adds an asynchronous method to lock the startup files using the same
lock that we use during normal startup.
The profile service then uses this lock to gate access to the profiles.ini
files adding a method to async flush the entire database or in the case
that the on-disk database has changed a way to mergwe in some properties
about the current profile into the on-disk version.
Differential Revision: https://phabricator.services.mozilla.com/D222662
The issue was that we weren't getting the values given through experiment.
With this patch, the Set as default native prompt can be controlled through
the experiments.
Differential Revision: https://phabricator.services.mozilla.com/D225815
This was used by toolchain and spidermonkey tasks prior to bug 1569900
and bug 1469697; since then they use run-task to check out the repo
instead.
Differential Revision: https://phabricator.services.mozilla.com/D225981
On 64-bit Windows (x86_64, aarch64), stack walking relies on
RtlLookupFunctionEntry to navigate from one frame to the next. This
function acquires up to two ntdll internal locks when it is called.
The profiler and the background hang monitor both need to walk the
stacks of suspended threads. This can lead to deadlock situations,
which so far we have avoided with stack walk suppressions. We guard some
critical paths to mark them as suppressing stack walk, and we forbid
stack walking when any thread is currently on such path.
While stack walk suppression has helped remove most deadlock situations,
some can remain because it is hard to detect and manually annotate all
the paths that could lead to a deadlock situation. Another drawback is
that stack walk suppression disables stack walking for much larger
portions of code than required. For example, we disable stack walking
for LdrLoadDll, so we cannot collect stacks while we are loading a DLL.
Yet, the lock that could lead to a deadlock situation is only held
during a very small portion of the whole time spent in LdrLoadDll.
This patch addresses these two issues by implementing a finer-grained
strategy to avoid deadlock situations. We acquire the pointers to the
internel ntdll locks through a single-stepped execution of
RtlLookupFunctionEntry. This allows us to try to acquire the locks
non-blockingly so that we can guarantee safe stack walking with no
deadlock.
If we fail to collect pointers to the locks, we fall back to using stack
walk suppressions like before. This way we get the best of both worlds:
if we are confident that the situation is under control, we will use the
new strategy and get better profiler accuracy and no deadlock; in case
of doubt, we can still use the profiler thanks to stack walk
suppressions.
Differential Revision: https://phabricator.services.mozilla.com/D223498
The encoder classes already have strong references to the resources they
rely upon. That is enough to prevent those resources from being
released before the encoder. That's all we need! Including the resources
in cycle checking is just making it possible for the resource and the
encoder to be unlinked in the same cycle, in arbitrary order. That's
dangerous because it's the same outcome as if the encoder didn't have a
strong reference to the resource at all.
Differential Revision: https://phabricator.services.mozilla.com/D225914
--lwt-tab-loading-fill-inactive is only set by built-in colorway themes, which have been migrated to AMO where they can't set that variable. Built-in copies are slated for removal (bug 1815898).
Differential Revision: https://phabricator.services.mozilla.com/D225948
The local time components aren't stored in separate slots, but instead in a
single slot which stores the number of seconds since the start of the year.
Differential Revision: https://phabricator.services.mozilla.com/D225927
These functions return the cached local date-time values, so we just need
the `DateFillLocalTimeSlots` CacheIR op from part 2, followed by reading the
corresponding slot.
Differential Revision: https://phabricator.services.mozilla.com/D225926
