Repository navigation
[wasi] Cannot find host wasmtime #100394
Description
Wasi.Build.Tests.ILStripTests.WasmStripILAfterAOT_TestDefaultAndOverride(stripILAfterAOT: "", expectILStripping: True, singleFileBundle: False) [FAIL]
Expected 0 exit code but got 255: /root/helix/work/workitem/e/dotnet-latest/dotnet run --no-silent --no-build -c Release
Standard Output:
[Release_3ubcj3n5_xxb] WasmAppHost --runtime-config /root/helix/work/workitem/e/wbt artifacts/Release_3ubcj3n5_xxb/bin/Release/net9.0/wasi-wasm/AppBundle/Release_3ubcj3n5_xxb.runtimeconfig.json --no-silent
[Release_3ubcj3n5_xxb] Error: Cannot find host wasmtime: Tried to look for wasmtime in PATH: /root/helix/work/workitem/e/dotnet-latest, /root/helix/work/correlation/dotnet-latest, /root/helix/work/correlation/xharness-cli, /root/helix/work/correlation/dotnet-cli, /root/helix/work/correlation/wasi-sdk, /root/helix/work/correlation/wasmtime, /home/helixbot/.jsvu/bin, /usr/local/sbin, /usr/local/bin, /usr/sbin, /usr/bin, /sbin, /bin .
Build Information
Build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=621924
Error Message
{
"ErrorMessage": "Cannot find host wasmtime",
"BuildRetry": false,
"ExcludeConsoleLog": false
}Known issue validation
Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=621924
Error message validated: [Cannot find host wasmtime]
Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 3/28/2024 9:09:15 AM UTC
Report
Summary
| 24-Hour Hit Count | 7-Day Hit Count | 1-Month Count |
|---|---|---|
| 0 | 0 | 30 |
Activity
dotnet-policy-service commentedon Mar 28, 2024
Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.
pavelsavara commentedon Mar 28, 2024
cc @akoeplinger
akoeplinger commentedon Mar 29, 2024
It looks like wasmtime is missing from the correlation payload which suggests to me something goes wrong here:
runtime/src/libraries/sendtohelix-wasi.targets
Lines 19 to 24 in 83b0d93
maraf commentedon Apr 4, 2024
Red hering - windows investigation - on windows everything works
From Build.binlog
WasmtimeDir = D:\a\_work\1\s\artifacts\obj\wasmtime\Downloading from "https://github.com/bytecodealliance/wasmtime/releases/download/v5.0.0/wasmtime-v5.0.0-x86_64-windows.zip" to "D:\a\_work\1\s\artifacts\obj\wasmtime-v5.0.0-x86_64-windows.zip" (3995602 bytes).From SendToHelix.binlog
WasmtimeDir = D:\a\_work\1\s\artifacts\obj\wasmtime\WasmtimeDirForHelixPayload = D:\a\_work\1\s\artifacts\obj\helix-staging\\wasmtimeOne of the corellation payload was empty (empty zip) https://helixde107v0xdeko0k025g8.blob.core.windows.net/helix-job-887530b8-8cc0-4dab-a4c8-242ff41fa82b18102e030f94a06bf/c7d44711-29d4-4ff7-944f-947d4f8dea8a.zip
It all seems correct from the binlog :/
From Build.binlog
We don't provision wasmtime on linux. It's preinstalled in the image. Could it be that copy fails because of some symlink or something?
I have tried to ignore
WASMTIME_PATH(system provided wasmtime) in #100664 and it worked. The corellation payload that is normally empty, contains wasmtime now.maraf commentedon Apr 5, 2024
I'm not seeing it anymore
EDIT: It happens sometimes and on linux lines only
7 remaining items
lewing commentedon Apr 24, 2024
Is this still matching the correct failures?
maraf commentedon Apr 25, 2024
@pavelsavara You saw this on lib tests, right? But all of the matches are from WBT 🤔
maraf commentedon Apr 25, 2024
pavelsavara commentedon Apr 25, 2024
I just saw
ls -lsatwice becauseBuildHelixItems->PrepareHelixCorrelationPayload_Wasiis called twice. InBuildand inTestwhich are separate MSBuild runs. I don't know why.I'm not sure about that, why you think so ?
It will get downloaded every time
maraf commentedon Apr 25, 2024
My bad, sorry
pavelsavara commentedon Apr 25, 2024
well maybe it will fix because you saw it on linux, which was using pre-installed. Now it will be fresh every time.
maraf commentedon Apr 25, 2024
That was my previous thinking, but later it looks like the files are there always, and then are deleted from staging folder
maraf commentedon Apr 25, 2024
Theory
sendtohelixhelp.projruns in parallel for two scenarios (workloads, noworkloads) EDIT: not scenario, but same loopStageDependenciesForHelix, because@(__HelixDependenciesToStageThatDontExist->Count()) > 0SendToHelixJob, but zips are already uploaded, reusing themStageDependenciesForHelix, because@(__HelixDependenciesToStageThatDontExist->Count()) == 0SendToHelixJob, which zips folders and upload themAccording to this theory, WASI SDK payloads shouldn't be always complete
pavelsavara commentedon Apr 25, 2024
workloads, noworkloads are not scenarios
lewing commentedon Apr 26, 2024
reopening for a few days to let the fix make it into pr builds