perma failing dom/base/test/browser_aboutnewtab_process_selection.js when running in non-e10s mode

RESOLVED FIXED in Firefox 57

Status

()

RESOLVED FIXED
a year ago
a year ago

People

(Reporter: jmaher, Unassigned)

Tracking

(Blocks: 1 bug)

unspecified
mozilla57
Points:
---

Firefox Tracking Flags

(firefox57 fixed)

Details

(Reporter)

Description

a year ago
we are turning on non-e10s mode for windows7-debug and there are a few perma failing tests already.

I found that dom/base/test/browser_aboutnewtab_process_selection.js is failing:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=01724ecb482db9bad166e86cf46ce32edbccb483&selectedJob=123699415&filter-searchStr=bc5

here is the log file:
https://queue.taskcluster.net/v1/task/Hy5CNaNVSIutKk7eZ4qINQ/runs/0/artifacts/public/logs/live_backing.log

and log lines related to the file:
22:10:37     INFO -  746 INFO TEST-START | dom/base/test/browser_aboutnewtab_process_selection.js
22:10:37     INFO -  GECKO(3544) | Chrome file doesn't exist: Z:\task_1502920097\build\tests\mochitest\browser\dom\base\test\head.js
22:10:37     INFO -  GECKO(3544) | ++DOMWINDOW == 23 (16808C00) [pid = 3544] [serial = 23] [outer = 1C602C00]
22:10:37     INFO -  TEST-INFO | started process screenshot
22:10:38     INFO -  TEST-INFO | screenshot: exit 0
22:10:38     INFO -  Buffered messages logged at 22:10:37
22:10:38     INFO -  747 INFO Entering test bound
22:10:38     INFO -  748 INFO Leaving test bound
22:10:38     INFO -  749 INFO Entering test bound
22:10:38     INFO -  750 INFO Leaving test bound
22:10:38     INFO -  Buffered messages finished
22:10:38    ERROR -  751 INFO TEST-UNEXPECTED-FAIL | dom/base/test/browser_aboutnewtab_process_selection.js | This test contains no passes, no fails and no todos. Maybe it threw a silent exception? Make sure you use waitForExplicitFinish() if you need it. -
22:10:38     INFO -  GECKO(3544) | [3544] WARNING: We've already scheduled a task for background list flush.: file z:/build/build/src/parser/html/nsHtml5TreeOpExecutor.cpp, line 288
22:10:38     INFO -  GECKO(3544) | MEMORY STAT | vsize 731MB | vsizeMaxContiguous 579MB | residentFast 246MB | heapAllocated 112MB
22:10:38     INFO -  752 INFO TEST-OK | dom/base/test/browser_aboutnewtab_process_selection.js | took 147ms
(Reporter)

Comment 1

a year ago
in order to get tests turned on faster, I will disable this for now.
(Reporter)

Comment 2

a year ago
this appears to fail for linux64-jsdcov (run on m-c only- which is linux64-opt but non-e10s)
This test definitely seems to be specific to e10s (and the preallocated process). Gabor, how do we make this not run in non-e10s mode?
Flags: needinfo?(gkrizsanits)
(In reply to Andrew Overholt [:overholt] from comment #3)
> This test definitely seems to be specific to e10s (and the preallocated
> process). Gabor, how do we make this not run in non-e10s mode?

Yes, that this is an e10s only test, I should have disabled it for non-e10s :(

(In reply to Joel Maher ( :jmaher) (UTC-5) from comment #2)
> this appears to fail for linux64-jsdcov (run on m-c only- which is
> linux64-opt but non-e10s)

Thanks! Actually that was the only reason I disabled for linux. I was not aware that jsdcov is non-e10s...

Anyway, I update the ini to only disable the test for non-e10s.
Flags: needinfo?(gkrizsanits)
(Reporter)

Comment 5

a year ago
can we close this bug out?
(In reply to Joel Maher ( :jmaher) (UTC-5) from comment #5)
> can we close this bug out?

I'm trying to land a simple patch here to reenable the test on linux and only keep the non-e10s part, just the tree is closed. Will close it out after that.

Comment 7

a year ago
Pushed by gkrizsanits@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/3aeae824965c
This test should be only disabled for non-e10s. r=me

Comment 8

a year ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/3aeae824965c
Status: NEW → RESOLVED
Last Resolved: a year ago
status-firefox57: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
You need to log in before you can comment on or make changes to this bug.