-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Freezes When Blazor WebAssembly publish #93076
Comments
Tagging subscribers to this area: @agocke, @sbomer, @vitek-karas Issue DetailsIs there an existing issue for this?
Describe the bugWhen I try to deploy my Blazor WebAssembly from Visual Studio to Azure, it freezes midway through. --enable-serialization-discovery --skip-unresolved true --notrimwarn --link-attributes "C:\Program Files\dotnet\sdk\7.0.401\Sdks\Microsoft.NET.ILLink.Tasks\build\6.0_suppressions.xml" When I tried the dotnet publish command, it also freezes. After adding the following to WebAssembly's csproj, the problem no longer occurs, so I think it is stuck in the middle of trimming.
The dll referenced by WebAssembly makes heavy use of reflection. Since it is a commercial software, I cannot attach those codes. WebAssembly and the dlls it references are made with .Net6. Expected BehaviorNo response Steps To ReproduceNo response Exceptions (if any)No response .NET VersionNo response Anything else?No response
|
Can you please share the version of the SDK you're using? If you look at the running processes when the publish is "hung", do you see a |
Thank you. Searching for $task ILLink in Search Log Two dotnet.exe's were consuming CPU while it was hanging.
|
Thanks a lot for the callstacks. We've had several issues around this code but most of them should be fixed in 7.0.401 which is what you're using. I can only think of one possible way which we've seen so far. The fix for that is basically this: #87634. The repro for that fix is based on analyzer - which has full method body CFG, which trimmer doesn't use, so it's not directly affected. But the trimmer does use the iterative analysis from interprocedural analysis around compiler generated code. I guess it's possible to create a state similar to the one in the analyzer around that. I played with it for a while, but couldn't make it to break. @Ishikawa-Tatsuya you could check what code makes this a problem. When you have it under the debugger, go to this frame
And look at the @sbomer Is there a magical incantation which can be used to run the 8.0 linker in 7.0 SDK targeting a 6.0 app? That way we could validate that this problem is fixed in 8 - without retargeting the app which could be a lot of work I guess. Separately this raises a question: Should we proactively fix the "hang"/"crash" fixes we've made in 8 to 7.0 linker? Specifically I'm thinking:
|
I checked ProcessMethod and found out the method being processed there. I then tried changing the related assemblies to 7.0, but it froze as well.
|
I found that if I rewrite this line, it no longer freezes. //if (ps.Length == 1 && ps[0].ParameterType.IsArray) args = new[] { args };
I also found that this phenomenon occurred even when I simply added the above code to her BlazorWebAssebly that I had just created. |
Thanks a lot - I can repro it as well. Still looking through what's going on... and why it loops. |
I can also confirm that this doesn't repro on .NET 8 illink - so we've fixed it - somewhere :-). Still don't know which change fixed it though. It looks a little like recursive arrays, but not fully recursive, only in value not actual reference recursive. |
Thank you. My project plans to replace .NET8 once it is released. Until then, I will deal with it temporarily. |
Really simple repro (Edit: even simpler): // Force state machine
static async Task TestRec ()
{
typeof (TestType).RequiresAll (); // Force data flow analysis
object[] args = null;
args = new[] { args };
} On .NET 7 this hangs both the analyzer and illink. |
It is recursive - but it's an overwrite, so we don't hit the direct recursion (which would have crashed the trimmer). It's only recursive due to the state machine, which will continuously expand the possible values - effectively recursively. I assume that once it hits certain size it "hangs" because just equality is too expensive to compute, but eventually it would likely crash with stack overflow as well. |
😢 |
This a bug - we need to fix it. There's nothing wrong with the pattern as such, it's just uncovering a limitation in the trim analysis. |
This adds a test for a repro of dotnet#93076 (reproes only on .NET 7).
Yes, I think we should. Did you figure out which change fixed this in 8.0? |
Not yet - I think the change which prevents nested arrays will fix this as well, but I have to port it first. |
So porting trimmer/analyzer parts of #82818 fixed the problem for trimmer. Analyzer hangs on a different test from the suite - so it's probably the other bug to port. |
This adds a test for a repro of #93076 (reproes only on .NET 7).
I created a PR to port the relevant fix to 7.0: dotnet/linker#3231 |
Update: We hope to be able to port 2 more (3 total) stability fixes from 8 to 7: dotnet/linker#3234 |
Is there an existing issue for this?
Describe the bug
When I try to deploy my Blazor WebAssembly from Visual Studio to Azure, it freezes midway through.
Here is the information that will be displayed in the output window at the end.
--enable-serialization-discovery --skip-unresolved true --notrimwarn --link-attributes "C:\Program Files\dotnet\sdk\7.0.401\Sdks\Microsoft.NET.ILLink.Tasks\build\6.0_suppressions.xml"
When I tried the dotnet publish command, it also freezes.
After adding the following to WebAssembly's csproj, the problem no longer occurs, so I think it is stuck in the middle of trimming.
The dll referenced by WebAssembly makes heavy use of reflection.
That dll is also created by me and also references Microsoft.CodeAnalysis.CSharp.
Since it is a commercial software, I cannot attach those codes.
Also, since I have not determined which code caused the problem, I cannot attach the minimum reproduction environment.
WebAssembly and the dlls it references are made with .Net6.
Expected Behavior
No response
Steps To Reproduce
No response
Exceptions (if any)
No response
.NET Version
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered: