Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test failures: GCStress time out in tracing pauseonstart, reverse tests #38524

Closed
BruceForstall opened this issue Jun 28, 2020 · 5 comments
Closed

Comments

@BruceForstall
Copy link
Member

tracing\eventpipe\pauseonstart\pauseonstart\pauseonstart.cmd and tracing\eventpipe\reverse\reverse\reverse.cmd in various GCStress modes, such as

CoreCLR Windows_NT x64 Checked gcstress0xc_zapdisable @ Windows.10.Amd64.Open
CoreCLR Windows_NT x86 Checked gcstress0xc_zapdisable_heapverify1 @ Windows.10.Amd64.Open
CoreCLR Windows_NT x64 Checked gcstress0xc_zapdisable_heapverify1 @ Windows.10.Amd64.Open

(there may be more)

with time outs, e.g.:

        126.7s: Sending 'exit' to subprocess stdin
        131.8s: Subprocess didn't exit in 5 seconds!
        132.2s: System.TimeoutException: Subprocess didn't exit in 5 seconds
           at Tracing.Tests.Common.Utils.RunSubprocess(Assembly currentAssembly, Dictionary`2 environment, Func`1 beforeExecution, Func`2 duringExecution, Func`1 afterExecution) in /Users/runner/runners/2.171.1/work/1/s/src/coreclr/tests/src/tracing/eventpipe/common/IpcUtils.cs:line 120
        132.3s: Calling process.Kill()
        132.3s: Subprocess stdout: 
          0.6s: The runtime has been configured to pause during startup and is awaiting a Diagnostics IPC ResumeStartup command from a server at 'DOTNET_TRACE_TESTS_t4qv4kkd.j3d'.
          9.7s: Subprocess started!  Waiting for input...
        132.3s: Subprocess stderr: 
        132.6s: Test passed: False

These stress modes significantly slow down the process, so it is not surprising that a short 5 seconds timeout is not sufficient.

The timeouts should be significantly increased. Or perhaps these should not be run under GCStress.

@BruceForstall BruceForstall added this to the 5.0.0 milestone Jun 28, 2020
@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added the untriaged New issue has not been triaged by the area owner label Jun 28, 2020
BruceForstall added a commit to BruceForstall/runtime that referenced this issue Jun 28, 2020
@BruceForstall
Copy link
Member Author

PR to disable for GCStress: #38525

BruceForstall added a commit that referenced this issue Jun 29, 2020
@tommcdon
Copy link
Member

@josalem

@tommcdon tommcdon removed the untriaged New issue has not been triaged by the area owner label Jun 29, 2020
@josalem
Copy link
Contributor

josalem commented Jun 29, 2020

Thanks @BruceForstall! PR should be out later today!

@josalem
Copy link
Contributor

josalem commented Jun 29, 2020

Actually this should be fixed by #38474 which removes the internal timeouts in favor of letting Helix timeout if something goes wrong.

@tommcdon
Copy link
Member

closing per @josalem's comment that #38474 addresses this. GCStress lengthens the time the test runs and so the test timeout was removed.

@ghost ghost locked as resolved and limited conversation to collaborators Dec 8, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants