This patch fixes a minor issue with manifestparser when it is used in python 3. The problem was that dict.items() returns a generator in python 3 instead of a list.
Differential Revision: https://phabricator.services.mozilla.com/D53953
--HG--
extra : moz-landing-system : lando
There are frequent shutdown hangs in this directory. Making us reuse
content processes when Fission is enabled has papered over the
shutdown hangs from reader mode tests in other directories, so
hopefully it will help here, too.
Differential Revision: https://phabricator.services.mozilla.com/D54012
--HG--
extra : moz-landing-system : lando
This turns off the telemetry to Tiles in m-c. Activity Stream related telemetry to Tiles will be handled separately.
Differential Revision: https://phabricator.services.mozilla.com/D53875
--HG--
extra : moz-landing-system : lando
In short - if a user forcibly terminates the browser because it seems
to be permanently hung, we currently do not get a change to record the
hang. This is unfortunate, because these likely represent the most
egregious hangs in terms of user frustration. This patch seeks to
address that.
If a hang exceeds 8192ms (the current definition of a "permahang" in
existing BHR terms), then we decide to immediately persist it to disk,
in case we never get a chance to return to the main thread and
submit it. On the next start of the browser, we read the file from
disk on a background thread, and just submit it using the normal
mechanism.
Regarding the handling of the file itself, I tried to do the simplest
thing I could - as far as I can tell there is no standard simple
serialization mechanism available directly to C++ in Gecko, so I just
serialized it by hand. I didn't take any special care with endianness
or anything as I can't think of a situation in which we really care
at all about these files being transferable between architectures. I
directly used PR_Write / PR_Read instead of doing something fancy
like memory mapping the file, because I don't think performance is a
critical concern here and it offers a simple protection against
reading out of bounds.
Differential Revision: https://phabricator.services.mozilla.com/D52566
--HG--
extra : moz-landing-system : lando
This patch bascially changes the test to use the SpecialPowers.spwan()
instead of the ContentTask.spawn(). It also adds code to ensure the
content proces is shut down entirely while it involves workers in the
test. Because it would have a timing issue if we reopen a page which
used a worker before immediately after it has been closed.
Differential Revision: https://phabricator.services.mozilla.com/D53788
--HG--
extra : moz-landing-system : lando
Note that the `stackPointer == 0` assertion would crash anyway, so this
shouldn't add crashes. But it should make these new crashes appear separate,
making them hopefully easier to find and analyze.
Differential Revision: https://phabricator.services.mozilla.com/D52524
--HG--
extra : moz-landing-system : lando
When the profiler shuts down, it destroys all remaining `RegisteredThread`'s,
including the embedded ProfilingStack that stores labels for each thread.
Now, it is possible that some threads may outlive the profiler (e.g., Rayon
threads, which cannot be synchronously shut down), so there could be labels left
when the `ProfilingStack` gets destroyed, which triggers the `stackPointer == 0`
assertion in the destructor.
Removing the assertion would not be enough, because after that, the thread may
still try to pop labels (using a pointer to the now-destroyed `ProfilingStack`
stored in `AutoProfilerLabel`), causing a UAF.
`AutoProfilerLabel` could theoretically check that the profiler is still alive
before trying to pop labels, but that would add a significant cost every time
the `ProfilingStack` is accessed, because the profiler mutex would need to be
locked.
The solution here is to make `ProfilingStack` a separate heap object, owned
both by the profiler through the thread's `RegisteredThread`, and by the thread
itself through the thread-local `sProfilingStackOwnerTLS`.
The first owning link is severed when the profiler shuts down.
The other owning link is severed when the thread unregisters itself (before or
after shutdown).
This way the `ProfilingStack` stays alive as long as needed by the thread, even
if it outlives the profiler.
Implementation detail: `ProfilingStack` is used in other places as a straight
object, so it cannot be made ref-counted itself. Instead we use
`ProfilingStackOwner`, a small ref-counted shell around it.
Differential Revision: https://phabricator.services.mozilla.com/D49141
--HG--
extra : moz-landing-system : lando
Currently DocumentChannelParent serves two fairly separate functions.
It acts as a logic controller for a connecting load (ultimately on behalf of a CanonicalBrowsingContext), that creates a channel and once it gets a response, figures out the right thing to do with it (send to the originating process, send to a new process, handle as a download etc).
It's the parent-side IPDL actor for an nsIChannel implementation that we hold in the docshell as a placeholder while the above happens. This is largely a backwards compatibility hack since docshell expects to have a channel when a load has been initiated (but in the future we could do loads more directly through BrowsingContext and rewrite docshell to understand waiting on that).
This patch splits this into two separate classes (and adds more documentation explaining exactly what each one does). It shouldn't affect any behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D53383
--HG--
rename : netwerk/ipc/DocumentChannelParent.cpp => netwerk/ipc/DocumentLoadListener.cpp
extra : moz-landing-system : lando
Changes:
Add Ubuntu 18.04 `dockerfile`, support files and `ubuntu1804-test-system-setup.sh` that slightly differs from `ubuntu1604-test-system-setup.sh` in package contents.
Add a temporary flag to `try fuzzy` selector, taskcluster decision and taskgraphs to enable selection of Ubuntu 18.04 docker image to run linux tests.
Differential Revision: https://phabricator.services.mozilla.com/D53750
--HG--
extra : moz-landing-system : lando
It can be null after FreeInnerObjects.
Though it looks a bit spooky for chrome code to poke at a window in that state?
We should at least figure out which change made this such a high-volume crash.
This should unblock nightly updates for now... I can add an assertion when
called from DOM bindings if you want, so that we catch this on debug builds at
least?
Differential Revision: https://phabricator.services.mozilla.com/D53967
--HG--
extra : moz-landing-system : lando
Explicit initialization of these static pointers appears to resolve these intermittent failures.
Differential Revision: https://phabricator.services.mozilla.com/D53842
--HG--
extra : moz-landing-system : lando
Assertions on the type of an IPDL-defined union before accessing it are redundant,
since the generated accessors already contain a MOZ_RELEASE_ASSERT for checking
the type. Redundant assertions unnecessarily clutter the code, so they are removed.
Differential Revision: https://phabricator.services.mozilla.com/D53797
--HG--
extra : moz-landing-system : lando
OpenCommon now removes the root content object, so those parts of the big
comment don't look relevant anymore. And tests pass with this change...
I _think_ this does not reintroduce bug 253951, but I'm not 100% how to check.
Differential Revision: https://phabricator.services.mozilla.com/D52602
--HG--
extra : moz-landing-system : lando
Instead of trying to understand the precise Control Flow Graph, we now construct
MIR more like how a baseline compiler does it: whenever we have a forward jump
in the bytecode we add the block to a pendingBlocks list (keyed on the target
pc) and when we get to a jump target op we "link" any pending blocks for that
pc.
This patch also changes 'continues' in while/for-in/for-of loops to be more
similar to continues in for-loops and do-while loops. They're now just forward
jumps to the end of the loop body, instead of backward jumps to the branch at
the top that jumps to the condition. It's simpler and because they're now plain
forward branches the PendingBlock system handles them automatically.
We still always emit a jump target op for continues, even if there are no
continues. It's pretty easy to optimize this but that will be done in a
follow-up (bug 1595699) to not complicate this patch more. We can likely also
remove some source notes.
Differential Revision: https://phabricator.services.mozilla.com/D52635
--HG--
extra : moz-landing-system : lando
