Closed Bug 1552682 Opened 4 months ago Closed 4 months ago

Unable to run WPT test locally, got stuck at "WARNING No generated manifest found"

Categories

(Testing :: web-platform-tests, defect, P2, major)

Version 3
defect

Tracking

(firefox69 fixed)

RESOLVED FIXED
mozilla69
Tracking Status
firefox69 --- fixed

People

(Reporter: violet.bugreport, Assigned: jgraham)

Details

Attachments

(1 file)

STR:

Run command:

./mach wpt testing/web-platform/tests/css/filter-effects/parsing/filter-computed.html

Expected result:

WPT test should start running.

Actual result:

$ ./mach wpt testing/web-platform/tests/css/filter-effects/parsing/filter-computed.html
0:02.87 WARNING No generated manifest found

then it gets stuck at this point without any progress even after 10min.

I've already tried clobber rebuild, and reboot. Nothing changed.

Note: WPT test worked fine for me before and I haven't done anything special on my machine. It just suddenly stopped working now.

Is this on Windows? Does the system monitor show activity.

Regenerating the manifest can be super-slow which is why we try to avoid it as much as possible. 10 minutes is long but on the wrong platform/hardware not impossible. So I think the question here is why we are falling off the fast path. Which revision are you on? Can you try running with --log-mach-level=debug?

Priority: -- → P2

I'm on Linux (Ubuntu 18.04).

I've followed your suggestion by running the command again and keep waiting, this time the test started running after 6min, the CPU has ~50% load during this period.

Although the problem is resolved now, it's still very strange since I haven't encountered this problem before, even in the first time when I ran a WPT test.

I'm wondering if it'd be better to inform the user to keep waiting patiently when WARNING No generated manifest found is shown? I'm pretty sure I've waited more than 10min yesterday before filing this bug, in that case user might think the test runner is broken and stop waiting.

Like I say I think the real issue is that we shouldn't end up requiring local manifest generation in almost any case; we should always download and update if possible. Did you manage to collect any debug logging? Is your branch unusual in someway (do you have lots of commits since central or changes under testing/web-platform/tests, for example?)

Did you manage to collect any debug logging?

Sorry I haven't saved the logging, because there was almost no logging (~3 messages) before the warning when I passed --log-mach-level=debug.

I recall one of the messages was like DEBUG hg.mozilla.org/mozilla-central/json...changeset..., not sure if it helps.

do you have lots of commits since central or changes under testing/web-platform/tests, for example?

That's true. Yesterday when I first discovered this problem, there was a ~13 patch stack rooted at a central commit from a few days ago. Because the WPT couldn't run, I pull the latest central commit and rebase the patch stack then did a clobber build, and that didn't help either.

To clarify, when I discovered the problem, I was at the top of my 13 patch stack; when I did the clobber build, I was at a central commit.

It seems like bool(req) was evaluated as False and there were several error
paths where we didn't fall back to a reasonable default URL. Fixing this should
mean we almost never fall back to not downloading anything

Pushed by james@hoppipolla.co.uk:
https://hg.mozilla.org/integration/autoland/rev/561a328e09ea
Fix fallback for wpt manifest download, r=ato
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69
You need to log in before you can comment on or make changes to this bug.