-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
[browser][publish] Windows has problems with AOT build/publish for long paths #103625
Comments
Tagging subscribers to 'arch-wasm': @lewing |
From what I know we open metadata stuff with |
@BrzVlad thanks for ideas but the proposed fixes are not enough. Do we have a way to dump stack trace? We are getting to
It does not print anything (debug mode). |
I don't think we have something to dump native stack. I used in the past for various reasons the However, I thought the error happens during app compilation ? My understanding that this is during aot compilation to llvm bytecode ? So I don't think it makes sense to use browser api ? |
If you are running a desktop program, you could always make it assert when that error is set and then I think it would ask you automatically to attach with VS where you can get stack trace and other things. |
Yes, it's app build step and yes, JS code does not make sense, though that was the only stack trace dump I found in the code.
The problems are with WASM app. |
I would strongly advise against gating the long path (the |
Thank you. I changed the snipped in the description to always append the prefix. Does any reason for |
Have you tried |
From grepping around, you may need to edit |
@ilonatommy is there work left for 9.0 here? |
Yes, I cannot find the proper place that has to be fixed and I got stuck with the PR that is linked to it (#103766), with no idea how to proceed. |
@jeromelaban shared this workaround <Target Name="_WorkaroundEmscriptenPathLength" Condition=" '$(OS)' == 'Windows_NT' " BeforeTargets="_SetupEmscripten">
<Exec Command="mklink /J "$(TMP)\emsdk" "$(EmscriptenSdkToolsPath)..\tools\"" ContinueOnError="true" />
<PropertyGroup>
<EmscriptenSdkToolsPath>$(TMP)\emsdk\</EmscriptenSdkToolsPath>
<EmscriptenUpstreamBinPath>$(EmscriptenSdkToolsPath)bin\</EmscriptenUpstreamBinPath>
<EmscriptenUpstreamEmscriptenPath>$(EmscriptenSdkToolsPath)emscripten\</EmscriptenUpstreamEmscriptenPath>
</PropertyGroup>
<ItemGroup>
<EmscriptenPrependPATH Remove="@(EmscriptenPrependPATH)" />
<EmscriptenPrependPATH Include="$(EmscriptenUpstreamBinPath)" />
<EmscriptenPrependPATH Include="$(EmscriptenUpstreamEmscriptenPath)" />
</ItemGroup>
</Target> |
Without the workaround, here's the output:
Repro in azure deovops: pool:
vmImage: 'windows-2022'
trigger:
- main
- release/*
stages:
- stage: Build
jobs:
- job: Build
steps:
- checkout: self
clean: 'true'
fetchDepth: 0
- pwsh: |
$DotNetRoot = "C:\Program Files\dotnet"
Invoke-WebRequest "https://dot.net/v1/dotnet-install.ps1" -OutFile ".\installcli.ps1"
& .\installcli.ps1 -c 9.0 -q daily -InstallDir $DotNetRoot
condition: and(succeeded(), eq( variables['Agent.OS'], 'Windows_NT' ))
displayName: 'Setup .NET (Windows)'
- pwsh: |
dotnet nuget add source -n "dotnet-public" https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-public/nuget/v3/index.json
dotnet nuget add source -n "dotnet-tools" https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-tools/nuget/v3/index.json
dotnet nuget add source -n "dotnet-eng" https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-eng/nuget/v3/index.json
dotnet nuget add source -n "dotnet-libraries" https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-libraries/nuget/v3/index.json
dotnet nuget add source -n "dotnet-libraries-transport" https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-libraries-transport/nuget/v3/index.json
dotnet nuget add source -n "dotnet9" https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet9/nuget/v3/index.json
dotnet nuget add source -n "dotnet9-transport" https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet9-transport/nuget/v3/index.json
dotnet nuget add source -n "dotnet10" https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet10/nuget/v3/index.json
dotnet nuget add source -n "dotnet10-transport" https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet10-transport/nuget/v3/index.json
displayName: Setup feeds
- pwsh: |
dotnet --version
dotnet --list-sdks
dotnet workload list
dotnet workload install wasm-tools
dotnet workload install wasm-experimental
displayName: Setup Workloads
- pwsh: dotnet new wasmconsole -o testconsole01 -f net9.0
- pwsh: |
cd testconsole01
mkdir $env:TMP\emsdk
dotnet publish -p:WasmCachePath=$env:TMP\emsdk -p:WasmBuildNative=true /bl:$(Build.ArtifactStagingDirectory)\msbuild.binlog
- task: PublishPipelineArtifact@1
condition: always()
inputs:
targetPath: $(Build.ArtifactStagingDirectory)
artifactName: dotnet-sdk-binaries Associated binlog: msbuild (15).zip |
Thank you. Similarly, I can reproduce on azure, locally not. In both cases emsdk paths are same ( ToDo: |
@ilonatommy The only notable difference that I could see is the fact that the sources and the workload are not on the same drive. This is why I chose to put the |
Different drive does not help, I have a local project that produces 1:1 same |
Reproduction:
Wasm.Build.Tests.Blazor.BuildPublishTests
- edit id to be$"blz_aot_{config}_{GetRandomId()}_TEST_OF_EXTREMELY_LONG_PATH"
, or anything that will result in path longer than 260 chars.g_fopen
code:and can be fixed by editing
g_fopen (const gchar *path, const gchar *mode)
fromgfile.c
to:Further errors come from
aot_printerrf (acfg, "Failed to load methodspec 0x%x due to %s.\n", token, mono_error_get_message (error));
inaot-compiler.c
.They are caused by
mono_get_method_checked
fromloader.c
getting emptyresult
but I am not able to track down the reason for it.cc @kg, @BrzVlad any ideas what might be going wrong there?
For debugging it is helpful to switch off parallelization of library precompiling in
MonoAOTCompiler
(PrecompileLibraryParallel
).The text was updated successfully, but these errors were encountered: