Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

radekdoulik
Copy link
Member

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.

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.
@radekdoulik radekdoulik requested a review from lewing April 5, 2023 16:08
@radekdoulik radekdoulik requested a review from radical as a code owner April 5, 2023 16:08
@ghost ghost added the area-Build-mono label Apr 5, 2023
@ghost ghost assigned radekdoulik Apr 5, 2023
@radekdoulik
Copy link
Member Author

We should probably freeze it only when user doesn't set another cache location. I will address that in the follow up PR to have the fix merged quickly.

The cache freezing was tested in #84253 draft.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

WasmTestOnBrowser-System.* test failures in CI
3 participants