This is a refactor. |start_logcat| allows filtering by tag and is used for
recording gecko.log for Marionette tests on Fennec.
MozReview-Commit-ID: 9NO6jQDMQ9E
--HG--
extra : rebase_source : e4f60b5d1c9c4ed6bb6dd237d9c1433b5f04a8d6
This works around issues with System Integrity Protection kicking in on OSX when
trying to run /usr/bin/lldb by attempting to using the version installed with
XCode's command line utilities.
In particular SIP prevents us from setting DYLD_LIBRARY_PATH which is needed
to run DMD.
Add FennecEmulatorRunner (for convenience), FennecRunner, FennecContext
and EmulatorAVD.
Common behaviour is defined in BaseEmulator and RemoteContext to distinguish
from B2G and Fennec specifics. I've tried to decouple ArchContext from
B2GContext, as well.
The emulator/adb commands in FennecRunner and EmulatorAVD are intended to
match the behaviour seen in current Android automation (e.g. mochitest).
MozReview-Commit-ID: 1tqD0DStdHR
--HG--
extra : rebase_source : 1450f3b03f82a0f9d33e43d19632a06a51ef7253
MozReview-Commit-ID: 9e6HNAaF0Yo
In case of in-process restarts it can happen that the new process gets forked into a new process group.
When that happens we loose the capability to kill the process. To prevent a hang when joining the output
reader threads in wait(), we simply skip that call by passing-through the IO error.
--HG--
extra : rebase_source : 702dfec407ed13114f59fa6ccb0d82c5b0790550
Sometimes the IO completion port doesn't shutdown child processes. When this happens,
mozprocess will attempt to force kill the child processes manually. However, there is
a bug here which causes the OSError to get raised.
Although this fixes that bug, the original issue(s) which prevented the IOC port
from signaling shutdown remain and are still undiagnosed.
MozReview-Commit-ID: L3DQPW0Is5v
--HG--
extra : rebase_source : cf6320cffea5a4c8fb5d62861c41065d9dcefa52
We can set MOZPROCESS_DEBUG to help debug windows process code. However on try
it is unreadable as there are multiple things using mozprocess, and each process
has multiple threads. It's impossible to tell which log message comes from where.
This improves the debug logs a bit by always specifying the PID and thread name.
There are a few other drive-by cleanups in this thread. The only one of note is
removing a python 2.5 only code path.
MozReview-Commit-ID: L3DQPW0Is5v
--HG--
extra : rebase_source : f07c07f53b06b1160cd3e70cb06b8dc12a89c3ab
This code is no longer used by Marionette client or elsewhere.
MozReview-Commit-ID: 4lx9CN7XIeH
--HG--
extra : rebase_source : e0a895c02939c51ee40be5be5f999cc41420a2a7
I believe this is the source of hangs/timeouts in automation.
join() waits forever. We add code to wait at most N seconds before
force terminating the process. The timeout is a bit high. But it is
better than infinite.
MozReview-Commit-ID: KwyO4RZ9OqL
--HG--
extra : rebase_source : 767d8ff5b48d7e75ab8fe72b18145446a38d439a
Before, we kept waiting for data in the pipe after receiving the
"done" message. This didn't really make much sense because the
"done" message should be the final thing sent over the pipe!
e9113fd6cdb8 (bug 1239939) recently dropped the poll interval
of the pipe from 1.0 to 0.1s. This appears to have introduced
an intermittent failure in a test. The race condition was
between the child process sending data and the parent process
timing out (after only 0.1s) waiting for that data. Increasing
the timeout makes the failure reproduce less often. Although
technically the race condition is still present! I'm not
inclined to fix it at this time, however.
The rationale for dropping the pipe timeout was that it was
causing lag when terminating short-lived processes. Now that
we abort the pipe reading/polling loop as soon as the "done"
message is received, we no longer poll the pipe after receiving
"done" and no longer have to worry about its timeout impacting
shutdown time.
MozReview-Commit-ID: EeENQ95RAs1
--HG--
extra : rebase_source : ce2502f32841a55f912aafdba7cc81e3a58e3ff5
Found this bug when auditing the code for issues. We are attempting
to send a tuple but were forgetting the trailing comma on a single
element tuple.
Fortunately, this doesn't appear to impact anything because
the receiving end of the pipe doesn't care what data it receives.
MozReview-Commit-ID: E34fBqxgUSq
--HG--
extra : rebase_source : 3701a28979a8b53d40ea68acef3ee2cb6d8a50f2
We add some system information including processor count
and memory sizes. We also add an "overall" section describing
total resource usage. This (surprisingly) wasn't defined.
This commit is the first in a series to reconcile the differences
between the JSON format in mozsystemmonitor and what
`mach build` writes so we can write a single tool to visualize
the data.
MozReview-Commit-ID: 9mdbKxeV9Ta
--HG--
extra : rebase_source : 3aadf5e83c91ba9553595f3da77ed7ca0e4d5541
We're currently running version 0.0 in automation. This version
doesn't have as_dict(), which means we can't easily save data
to JSON.
Bump the version to 0.1 in preparation of releasing a new
version.
MozReview-Commit-ID: Kr3JqyRXk5j
--HG--
extra : rebase_source : 89f763acaa12e4357f4a23f8772f99c1a0fdb56f
We have packages for 3.1.1 uploaded to our PyPI server used
for automation. There have been a number of bug fixes since the
version of psutil currently listed. Let's ensure we're running
a modern psutil to minimize our exposure to bugs on older
versions.
MozReview-Commit-ID: 6rDapZ8miFD
--HG--
extra : rebase_source : c66295828e0c95c4ffe57e579df41af508875027
This requires a change to how we process test manifests in the build system:
now, whenever we see a support file mentioned in a manifest, we require that
file isn't already in that test's support files, but if we see a support file
that was already seen in some other test, the entry is ignored, but it is not
an error. As a result of this change, several duplicate support-files entries
needed to be removed.
MozReview-Commit-ID: G0juyxzcaB8
--HG--
rename : testing/mozbase/manifestparser/tests/test_default_skipif.py => testing/mozbase/manifestparser/tests/test_default_overrides.py
