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

[wasm] Freeze the emscripten cache #84356

Merged
merged 1 commit into from
Apr 5, 2023

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
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