Intermittent toolkit/components/telemetry/tests/unit/test_SocketScalars.js | xpcshell return code: 0
Categories
(Toolkit :: Telemetry, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox-esr91 | --- | fixed |
firefox91 | --- | wontfix |
firefox92 | --- | fixed |
firefox93 | --- | fixed |
People
(Reporter: standard8, Assigned: robwu)
References
(Regression)
Details
(Keywords: intermittent-failure, regression)
Attachments
(2 files)
On Mac on the latest mozilla-central (f531f12e5), using a full build, I'm seeing test_SocketScalars.js
fail with the following log. This occurs both when running stand alone, and when running in parallel with other tests in the directory.
I'm attaching the full log from a run.
Comment 1•3 years ago
|
||
Seems to be cross-platform as it fails on Linux as well. Doesn't fail on CI. Doesn't fail when a debugger is attached.
Makes it almost impossible to determine when it started happening (I mean, I've noticed it for a while but since it never reproduced on try I assumed it was a local problem and ignored it. More fool, me).
Seems to be working and covering socket process collection adequately in non-local contexts, so I'm going to have this rather low on the priority list. Thank you for the report.
Assignee | ||
Comment 2•3 years ago
|
||
I've encountered several of these failures when I did a try push with many xpcshell tests at https://treeherder.mozilla.org/jobs?repo=try&revision=028b837991ba975f1864ef3047e01605754142c4&searchStr=xpcshell&selectedTaskRun=TXG-vJHBTAmJt0Zx0bzbRg.0
Failures observed on:
- test-macosx1015-64-qr/opt-xpcshell-e10s-2
- test-linux1804-64/debug-xpcshell-e10s-2
- test-macosx1015-64-qr/debug-xpcshell-e10s-1
- test-windows10-64-qr/opt-xpcshell-e10s-2
- test-windows10-64/opt-xpcshell-e10s-2
- test-linux1804-64/opt-xpcshell-e10s-3
- test-linux1804-64-qr/opt-xpcshell-e10s-3
- test-windows10-64-qr/debug-xpcshell-e10s-1
- test-linux1804-64-shippable/opt-xpcshell-e10s-3
- test-windows10-64-shippable-qr/opt-xpcshell-e10s-2
- test-windows10-64-devedition-qr/opt-xpcshell-e10s-2
Assignee | ||
Comment 3•3 years ago
|
||
I enabled some logging:
MOZ_LOG=nsIOService:5 ./mach xpcshell-test toolkit/components/telemetry/tests/unit/test_SocketScalars.js --verbose
The output now includes the following from https://searchfox.org/mozilla-central/rev/00977c4e37865a92f1c15572ae4aea90e934b25b/netwerk/base/nsIOService.cpp#520-523:
D/nsIOService nsIOService skipping LaunchSocketProcess because of the env
So apparently the test is failing because the socket process is unexpectedly not launching.
- The
MOZ_DISABLE_SOCKET_PROCESS
env var appears to be set whenmozInfo
includessocketprocess_networking
: https://searchfox.org/mozilla-central/rev/00977c4e37865a92f1c15572ae4aea90e934b25b/testing/xpcshell/runxpcshelltests.py#1188-1191 - The
socketprocess_networking
flag is set when the "network.http.network_access_on_socket_process.enabled" pref is true: https://searchfox.org/mozilla-central/rev/00977c4e37865a92f1c15572ae4aea90e934b25b/testing/xpcshell/runxpcshelltests.py#1516-1518
Based on the above analysis, I tried to start the test with the pref: MOZ_LOG=nsIOService:5 ./mach xpcshell-test toolkit/components/telemetry/tests/unit/test_SocketScalars.js --verbose --setpref=network.http.network_access_on_socket_process.enabled=true
... the test now crashed with MOZ_CRASH(Failed to get app path)
and the following stack:
#01: mozilla::ipc::GeckoChildProcessHost::FillMacSandboxInfo(_MacSandboxInfo&) (objdir/dist/NightlyDebug.app/Contents/MacOS/XUL + 0x9aabbc)
#02: mozilla::net::SocketProcessHost::FillMacSandboxInfo(_MacSandboxInfo&)
#03: mozilla::ipc::GeckoChildProcessHost::AppendMacSandboxParams(...)
#04: mozilla::ipc::GeckoChildProcessHost::AsyncLaunch(...)
#05: mozilla::ipc::GeckoChildProcessHost::LaunchAndWaitForProcessHandle(...)
#06: mozilla::net::SocketProcessHost::Launch()
#07: mozilla::net::nsIOService::LaunchSocketProcess()
Not sure how I should interpret this, but it seems like network.process.enabled
is forced to false unless the socketprocess
or socketprocess_networking
variant is enabled:
https://searchfox.org/mozilla-central/rev/00977c4e37865a92f1c15572ae4aea90e934b25b/taskcluster/taskgraph/transforms/tests.py#1622-1632
... which causes the test to pass trivially due to the early return: https://searchfox.org/mozilla-central/rev/00977c4e37865a92f1c15572ae4aea90e934b25b/toolkit/components/telemetry/tests/unit/test_SocketScalars.js#27-33
I'm not sure about what can be done to run the test, the best that I can think of is to skip the test in more situations (e.g. by adding run-if = socketprocess_networking
to the xpcshell.ini
file.
Updated•3 years ago
|
Comment 4•3 years ago
|
||
Updated•3 years ago
|
Comment hidden (Intermittent Failures Robot) |
Updated•3 years ago
|
Assignee | ||
Comment 6•3 years ago
|
||
Taking over since this smallish bug blocks the patch stack with bug 1723536 and bug 1723198.
Updated•3 years ago
|
Pushed by rob@robwu.nl: https://hg.mozilla.org/integration/autoland/rev/feb68b3ba329 Only run test_SocketScalars when there's a socket process r=janerik
Comment 8•3 years ago
|
||
bugherder |
Updated•3 years ago
|
Comment 9•3 years ago
|
||
bugherder uplift |
Comment 10•3 years ago
|
||
bugherder uplift |
Comment hidden (Intermittent Failures Robot) |
Description
•