Closed Bug 1344115 Opened 3 years ago Closed Last month

Cannot run |./mach web-platform-tests| due to |EnvironmentError: http server on port 8000 failed to start|

Categories

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

Version 3
x86_64
Windows 10
defect
Not set

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: masayuki, Unassigned)

Details

STR:

1. Building debug firefox x64 build (from the latest m-c) on Win10 with VS2015.
2. Try to run |./mach web-platform-tests|

Expected result:
starts to run web-platform-tests with the build.

Actual result:
not starts due to following error:

>  0:00.71 LOG: Thread-Log INFO STDOUT: DEBUG:manifest:Opening manifest at c:\mozilla\src\testing\web-platform\meta\MANIFEST.json
>  0:01.49 LOG: Thread-Log INFO STDOUT: DEBUG:manifest:Opening manifest at c:\mozilla\src\testing\web-platform\mozilla\meta\MANIFEST.json
>  0:48.65 LOG: MainThread INFO Using 1 client processes
>  0:53.05 LOG: MainThread INFO Closing logging queue
>  0:53.07 LOG: MainThread INFO queue closed
> Error running mach:
> 
>     ['web-platform-tests']
> 
> The error occurred in code that was called by the mach command. This is either
> a bug in the called code itself or in the way that mach is calling it.
> 
> You should consider filing a bug for this issue.
> 
> If filing a bug, please include the full output of mach, including this error
> message.
> 
> The details of the failure are as follows:
> 
> EnvironmentError: http server on port 8000 failed to start
> 
>   File "c:\mozilla\src\testing/web-platform/mach_commands.py", line 315, in run_web_platform_tests
>     return wpt_runner.run_tests(**params)
>   File "c:\mozilla\src\testing/web-platform/mach_commands.py", line 76, in run_tests
>     result = wptrunner.run_tests(**kwargs)
>   File "c:\mozilla\src\testing/web-platform/harness\wptrunner\wptrunner.py", line 157, in run_tests
>     test_environment.ensure_started()
>   File "c:\mozilla\src\testing/web-platform/harness\wptrunner\environment.py", line 207, in ensure_started
>     "%s server on port %d failed to start" % (scheme, port))

"netstat -aon | findstr :8000" doesn't list up any apps to use port 8000.

I didn't get anything special from raw-log too:

> {"source": "web-platform-tests", "thread": "Thread-Log", "time": 1488445246386, "action": "log", "message": "STDOUT: DEBUG:manifest:Opening manifest at c:\\mozilla\\src\\testing\\web-platform\\meta\\MANIFEST.json", "level": "INFO", "pid": 8072}
> {"source": "web-platform-tests", "thread": "Thread-Log", "time": 1488445247175, "action": "log", "message": "STDOUT: DEBUG:manifest:Opening manifest at c:\\mozilla\\src\\testing\\web-platform\\mozilla\\meta\\MANIFEST.json", "level": "INFO", "pid": 8072}
> {"source": "web-platform-tests", "thread": "MainThread", "time": 1488445247332, "action": "log", "message": "Using 1 client processes", "level": "INFO", "pid": 8072}
> {"source": "web-platform-tests", "thread": "MainThread", "time": 1488445251614, "action": "log", "message": "Closing logging queue", "level": "INFO", "pid": 8072}
> {"source": "web-platform-tests", "thread": "MainThread", "time": 1488445251618, "action": "log", "message": "queue closed", "level": "INFO", "pid": 8072}

My build config is:

> mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../fx64-dbg
> 
> mk_add_options MOZ_MAKE_FLAGS="-j12"
> 
> mk_add_options AUTOCLOBBER=1
> 
> ac_add_options --target=x86_64-pc-mingw32
> ac_add_options --host=x86_64-pc-mingw32
> 
> ac_add_options --enable-debug
> ac_add_options --enable-tests
> ac_add_options --enable-dmd
> ac_add_options --enable-profiling  # needed for --enable-dmd to work on Windows
> ac_add_options --enable-verify-mar

This is my first time to write/run web-platform-tests. Perhaps, there is something in my environment, but I don't know how to investigate it only from these information.

My environment is, Win10 x64 ja-JP, self-assembled PC.
And I use ESET Smart Security, but even if I disabled its Firewall, I got same result.
Hmm, the ESET Insernet Security 10 blocks to run web-platform-tests. If I disable realtime file protection of local drives, the problem has gone. However, even if I exclude C drive from the target, I still see ESET to block the tests. I continue to investigate what directly causes this...
Even after I uninstalled ESET Internet Security 10 (of course, rebooted my machine), I randomly meet this bug. Roughly, I see this error 9 times when I try to run 10 times. Very annoying and blocking my work...
IOError.strerror is written in Japanese, so, I'm not sure the exact error message in English, though.

I got "Couldn't connect because it's refused by the target computer". Even if I got this error randomly when I disable Firewall of Windows and Security app of Windows.
Hmm, so this is working for me with a Windows 10 VM from [1]. Are you sure that nothing else could be using the port? (e.g. I know that when one installs a treeherder under linux vm it uses port 8000 on the host, but that isn't listed in lsof -i :8000). Maybe something in the Windows Subsystem for Linux? Otherwise does it help to change the default port in testing/web-platform/harness/wptrunner/config.json?

[1] https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/
(In reply to James Graham [:jgraham] from comment #6)
> Are you sure
> that nothing else could be using the port? (e.g. I know that when one
> installs a treeherder under linux vm it uses port 8000 on the host, but that
> isn't listed in lsof -i :8000).

Yes, as I said in comment 0, "netstat -aon | findstr :8000" doesn't list up any apps to use port 8000. And if somebody uses the port, I shouldn't be able to run |./mach web-platform-tests| permanently. But I can run it randomly (but the time loss isn't so few).

> Maybe something in the Windows Subsystem for Linux?

I just use MozillaBuild. So, there is only MSYS.

> Otherwise does it help to change the default port in
> testing/web-platform/harness/wptrunner/config.json?

No. I see same error message except the port number.

Masayuki, is this still a problem for you? If yes, maybe bug 1561224 will help here given that I also see this on MacOS all the time but not only for HTTP but all test servers.

Assignee: nobody → hskupin
Status: NEW → ASSIGNED
Flags: needinfo?(masayuki)

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] (away July 6th - July 19th) from comment #8)

Masayuki, is this still a problem for you? If yes, maybe bug 1561224 will help here given that I also see this on MacOS all the time but not only for HTTP but all test servers.

Oh, I've forgotten this, but unfortunately, I've stopped using ESET Internet Security due to this bug. So, I cannot check it...

Flags: needinfo?(masayuki)

As such we should close the bug as incomplete.

Assignee: hskupin → nobody
Status: ASSIGNED → RESOLVED
Closed: Last month
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.