Closed Bug 1495310 Opened 1 year ago Closed 1 year ago
_google [taskcluster:error] Task aborted - max run time exceeded when Gecko 64 merges to Beta on 2018-10-15
46 bytes, text/x-phabricator-request
|Details | Review|
[Tracking Requested - why for this release]: Treeherder link: https://treeherder.mozilla.org/#/jobs?repo=try&resultStatus=testfailed,busted,exception,retry,runnable&revision=75e5bf1a70f520ee8ef65fb059ca93a4209b85f3&selectedJob=202472548 Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=202472548&repo=try&lineNumber=898 This seems to be from Bug 1493867 and Bug 1488554, Joel can you please take a look?
there are a few differences here: 1) firefox is started with this commandline: C:\Users\task_1538308922\build\application\firefox\firefox -wait-for-browser -no-deelevate -profile c:\users\task_1538308922\appdata\local\temp\tmp4gjopz\profile * but on beta today we don't have -wait-for-browser and we don't have -no-deelevate, these are new features on trunk- maybe they are not supported on beta 2) 15:19:47 INFO - PID 3288 | 1538320787056 addons.xpi-utils WARN Add-on email@example.com is not correctly signed. 15:19:47 INFO - PID 3288 | 1538320787059 addons.xpi-utils WARN Add-on firstname.lastname@example.org is not correctly signed. * I know we have changed addons quite a bit on trunk- maybe those models will not work on beta, and it looks to be identified by the two above bugs. I assume talos isn't the only thing broken- I assume all of talos will be broken by these changes.
Do the changes from bug 1488554 assume the launcher process is always enabled?
(In reply to Julien Cristau [:jcristau] from comment #2) > Do the changes from bug 1488554 assume the launcher process is always > enabled? Only 8461e2f532ed makes that assumption, mainly because AIUI Talos currently does not have the ability to run different tests depending on build configuration, which needs to happen when the launcher process is turned on. See also bug 1494698.
Oh, and wait-for-browser and no-deelevate do not affect Firefox when the launcher process is disabled.
First merge of central to beta repository is on Monday (2018-10-15). Please decide how to proceed.
Backing out of 8461e2f532ed as we merge to Beta should have sufficed. Can I get some confirmation here?
Flags: needinfo?(aklotz) → needinfo?(aryx.bugmail)
tp6 is still failing, xperf is fixed: Ignore the push with the green tp6 in between, that is on the FIREFOX_63b_RELBRANCH: https://treeherder.mozilla.org/#/jobs?repo=mozilla-beta&resultStatus=success%2Cusercancel%2Crunnable%2Ctestfailed%2Cbusted%2Cexception%2Cretry&group_state=expanded&tochange=5f2b0964547892553bc6af517074c87c19bd019d&searchStr=windows%2Ct-e10s%28tp6%29&fromchange=2920a2227ae0ca772ed45d2ac3b037180d3c0159&selectedJob=205905951
Flags: needinfo?(aryx.bugmail) → needinfo?(aklotz)
The launcher only affects xperf, not tp6. I suspect a different cause.
aswan, could this have something to do with the pageloader changes?
Possibly. The signing errors Joel mentioned in comment 1 certainly look like a problem. But I'm not sure how this works at all, we don't allow unsigned extensions at all on beta but a bunch of Talos tests use unsigned extensions... Joel, I vaguely remember that we talked about this a few weeks ago but I've already forgotten the resolution.
Flags: needinfo?(aswan) → needinfo?(jmaher)
this is windows tp6 specifically, this isn't linux tp6 or osx tp6. So in this case I would say that the pageloader changes are ok unless there is specific windows code. One thing that tp6 does is: MOZ_DISABLE_NONLOCAL_CONNECTIONS=0, and I believe that needs to be MOZ_DISABLE_NONLOCAL_CONNECTIONS=1 for unsigned extensions. Why would this work on linux/osx?
:aryx if you can push to try with raptor tp6 running that might be a solution here: https://searchfox.org/mozilla-central/source/taskcluster/ci/test/raptor.yml#35 we could then turn off talos tp6 and just use raptor. We are waiting for geckoProfile support before doing this on trunk, this should happen by the end of the month, so why not take something that runs reliably and use it instead.
What's needed to have raptor run on Try without |mach fuzzy|? https://searchfox.org/mozilla-central/source/taskcluster/ci/test/raptor.yml#35 has it set for try It belongs to raptor-firefox: https://searchfox.org/mozilla-central/source/taskcluster/ci/test/test-sets.yml#82 That should run for e.g. linx64/opt: https://searchfox.org/mozilla-central/source/taskcluster/ci/test/test-platforms.yml#44 Is anything in taskcluster/taskgraph/ different for raptor which would explain the difference? Thank you.
1 year ago
I am not aware of anything that would cause the difference. Could we try a push with ./mach try fuzzy and see? Also if it thinks that it is 'mozilla-beta' the jobs wouldn't run.
Looks like you or someone else added it to today's late beta sim: https://treeherder.mozilla.org/#/jobs?repo=try&resultStatus=testfailed%2Cbusted%2Cexception%2Csuccess%2Cretry%2Cusercancel%2Crunnable&tier=1%2C2%2C3&revision=4a7b8f464994b17a81710909331fff2f1d3626a0&searchStr=raptor Rap-C-e10s(tp6) is green.
I did an add new job- want to turn tp6 off for talos on beta and on for raptor on beta?
It's your domain. Fine for me.
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/208695a01a3b Enable Raptor Firefox tp6 and disable Talos tp6, both on beta r=jmaher
Do we need to do something on Beta still for this or was your push today meant to resolve this?
Assignee: nobody → aryx.bugmail
Let's keep this closed, getting raptor tp6 working/signed in bug 1501040 sounds easier and more future-proof.
1 year ago
Verified that T-e10s(tp6) doesn't run on beta.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.