[browser][publish] Windows has problems with AOT build/publish for long paths #103625
Comments
ilonatommy
added
arch-wasm
|
Tagging subscribers to 'arch-wasm': @lewing |
dotnet-policy-service
bot
added
the
untriaged
|
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 |
pavelsavara
removed
the
untriaged
|
@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-binariesAssociated 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_fopencode:and can be fixed by editing
g_fopen (const gchar *path, const gchar *mode)fromgfile.cto: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_checkedfromloader.cgetting emptyresultbut 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: