WasmTestOnBrowser-System.* test failures in CI #83655
Comments
stephentoub
added
blocking-clean-ci
|
Tagging subscribers to this area: @dotnet/area-infrastructure-libraries Issue DetailsBuild InformationBuild: https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_build/results?buildId=210176 Error MessageFill the error message using known issues guidance. {
"ErrorMessage": "WasmTestOnBrowser-System.Runtime.Tests",
"BuildRetry": false,
"ErrorPattern": "",
"ExcludeConsoleLog": false
}
|
|
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsBuild InformationBuild: https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_build/results?buildId=210176 Error MessageFill the error message using known issues guidance. {
"ErrorMessage": "WasmTestOnBrowser-System.Runtime.Tests",
"BuildRetry": false,
"ErrorPattern": "",
"ExcludeConsoleLog": false
}
|
|
From the logs it looks like the work item is timing out. @pavelsavara I did notice this warning though. Not sure if it's related: |
|
This is affecting other wasm test suites as well, e.g. |
That should not be related. The actual pinvoke is used only on windows, but our generator sees it. |
yeah, this should be harmless. |
|
@stephentoub The filter on the this issue is way too broad it appears to be picking up failures that are tracked in other errors like #80619 |
lewing
changed the title
|
Please feel free to narrow it however you think makes sense. The failures have been non-descript hangs and timeouts across multiple suites, failing lots of PRs. |
carlossanlop
added
area-Infrastructure-mono
and removed
area-Infrastructure-libraries
labels
lewing
changed the title
|
the non aot failure seems to always have Which is diffferent than the AOT failure which looks more like an extremely long compilation we were seeing an error similar to that in cc @pavelsavara |
just curious, what happens if there are two filters that match a fault. is it random which "wins"? @missymessa |
@danmoseley two different Known Issues tracking two different error messages? Or a single Known Issue that was set up with multiple error message (which, I don't think is a supported scenario)? (/cc @AlitzelMendez) If it's the first case where you have multiple Known Issues with different error messages and a failure happens to match on both, they'll both count it as a "hit". |
This fixes dotnet#83655 We prime the cache before packaging the emsdk cache package and also in docker images, so we don't need to update the cache, which might be in read-only location anyway. The underlying issue was problem with the cache lock: "C:/helix/work/correlation/build/emsdk/upstream/bin\clang.exe" --version cache:WARNING: Accessing the Emscripten cache at "C:\helix\work\correlation\build\emsdk\upstream\emscripten\cache" (for "sanity") is taking a long time, another process should be writing to it. If there are none and you suspect this process has deadlocked, try deleting the lock file "C:\helix\work\correlation\build\emsdk\upstream\emscripten\cache\cache.lock" and try again. If this occurs deterministically, consider filing a bug. cache:WARNING: Accessing the Emscripten cache at "C:\helix\work\correlation\build\emsdk\upstream\emscripten\cache" (for "sanity") is taking a long time, another process should be writing to it. If there are none and you suspect this process has deadlocked, try deleting the lock file "C:\helix\work\correlation\build\emsdk\upstream\emscripten\cache\cache.lock" and try again. If this occurs deterministically, consider filing a bug.
ghost
added
the
in-pr
This fixes #83655 We prime the cache before packaging the emsdk cache package and also in docker images, so we don't need to update the cache, which might be in read-only location anyway. The underlying issue was problem with the cache lock: "C:/helix/work/correlation/build/emsdk/upstream/bin\clang.exe" --version cache:WARNING: Accessing the Emscripten cache at "C:\helix\work\correlation\build\emsdk\upstream\emscripten\cache" (for "sanity") is taking a long time, another process should be writing to it. If there are none and you suspect this process has deadlocked, try deleting the lock file "C:\helix\work\correlation\build\emsdk\upstream\emscripten\cache\cache.lock" and try again. If this occurs deterministically, consider filing a bug. cache:WARNING: Accessing the Emscripten cache at "C:\helix\work\correlation\build\emsdk\upstream\emscripten\cache" (for "sanity") is taking a long time, another process should be writing to it. If there are none and you suspect this process has deadlocked, try deleting the lock file "C:\helix\work\correlation\build\emsdk\upstream\emscripten\cache\cache.lock" and try again. If this occurs deterministically, consider filing a bug.
ghost
removed
in-pr
|
going to leave this open until the fix is confirmed |
|
no hits in 24 hours, closing |
Build Information
Build: https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_build/results?buildId=210176
Build error leg or test failing: WasmTestOnBrowser-System.Runtime.Tests.WorkItemExecution
Pull request: #83651
Error Message
Fill the error message using known issues guidance.
{ "ErrorMessage": "", "BuildRetry": false, "ErrorPattern": "WasmTestOnBrowser.+ END OF WORK ITEM LOG: Command timed out, and was killed", "ExcludeConsoleLog": false }Report
Summary
The text was updated successfully, but these errors were encountered: