Runtime: Assertion at..., condition '<disabled>' not met.

Created on 16 Sep 2020  路  47Comments  路  Source: dotnet/runtime

I just published to Azure a Blazor Wasm SPA I am developing with VS Community 2019. The app starts up successfully in Chrome via the VS debugger, but the published version triggers the exception below (also in Chrome). The exception message, _ gives me no clue as to the problem_. This looks similar to this previous issue dotnet/aspnetcore#16818 that has been fixed. I published 2-3 months ago a much simpler early version of the app, which functionally did what's described below, and it worked at that time.

Curiously, after I first published a few minutes ago, my console log messages indicated the app got through almost all of my main layout's OnInitializedAsync code, including a JSRuntime.InvokeAsync to my JavaScipt initialization code that opens an IndexedDB and returns its Index of keys. But when I tried re-publishing and got the same exception, none of my initialization code ran according to the console log. I can post my OnInitializedAsync code, but since the exception is now happening before any of this code executes, I'm not sure it will be helpful. Any idea what's going on?

Thanks. Steve

App Startup Exception

area-Meta blocked blocking-release linkable-framework

Most helpful comment

Setting this as 5.0 and blocking as this is a pretty important scenario that is broken in Blazor WASM. I can reproduce it with the following steps:

dotnet new blazorwasm

edit the Pages/FetchData.razor file to add 
    Console.WriteLine(await Http.GetStringAsync("/"));
inside of the OnInitializedAsync method

dotnet publish -c Release

dotnet serve -d .\bin\Release\net5.0\publish\wwwroot\

navigate to http://localhost:8080/ and click on the "Fetch data" tab

(note you need to install https://github.com/natemcmaster/dotnet-serve to use dotnet serve)

I also verified that this worked on 5.0-preview8, but fails on 5.0-rc1.

All 47 comments

Thanks for contacting us.
Can you try out .NET 5.0 RC1 SDK and see whether you will meet the same error or not?

I am getting the same error with .NET 5.0 RC1. Here's the error message:
2020-09-17 10_16_30-Entwicklerwerkzeuge - IKON_2_0 - http___192 168 1 53_84_

Yep, same issue here. Only in the published version, everything works fine locally. Using RC1, worked fine with Preview 8.

Same issue here with RC1

After messing with this for awhile today, I was able to fix it on my end using the following workaround, and I hope it can help someone else.

The culprit was the HttpClient.GetStringAsync method. I replaced for example:

await HttpClient.GetStringAsync(page)

with

await (await HttpClient.GetAsync(page)).Content.ReadAsStringAsync();

After messing with this for awhile today, I was able to fix it on my end using the following workaround, and I hope it can help someone else.

The culprit was the HttpClient.GetStringAsync method. I replaced for example:

await HttpClient.GetStringAsync(page)

with

await (await HttpClient.GetAsync(page)).Content.ReadAsStringAsync();

It works. You saved my day. Thanks.

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. If it is closed, feel free to comment when you are able to provide the additional information and we will re-investigate.

See our Issue Management Policies for more information.

@mkArtakMSFT Can auto-close on this issue be prevented? It's a valid issue and the original reporter not responding does not mean that no one else of us will.

Okay, seems like that already did it.

Sorry for being so slow to get back in. I installed .Net 5.0 RC1. I verified that I am using VS 16.8, but am not sure if there is some other verification required to confirm other 5.0 RC1 things installed. Anyway, assuming I have done what was necessary, after I re-published, the app still fails to start-up because of the same exception, while still running successfully under the debugger in VS.

I don't have the situation lertoo mentioned.

Ugh. I just started to run into this exception in the VS debugger, in both v16.7.4 and v16.8.0 Preview 3.0 (.Net 5.0 RC1). That means I am dead in the water until I can either find the cause or a workaround. I could sure use some help.

I have a couple other small Blazor apps that are not running into this exception. So there is something about my one app that's triggering it.

I have tried, without success:

  1. Shutting down VS (both the v16.7 and v16.8 versions) and restarting.
  2. Rebooting my computer.
  3. Removing all the markup from my Layout that's invoked by App.razor
  4. Removing all the startup logic in my javascript.
  5. Removing all the code in my Layout's OnInitializedAsync and OnAfterRender overrides.
  6. Doing 3-5 together (i.e. the app would do nothing)
  7. Removing both the Found and NotFound component references in App.razor

Thanks for sharing details, everyone.
Can somebody please share a minimalistic repro project so we can root cause and address this? Thanks!

Tagging subscribers to this area: @tommcdon, @krwq
See info in area-owners.md if you want to be subscribed.

@eerhardt this seems to be caused by Linker

Tagging subscribers to this area: @brzvlad
See info in area-owners.md if you want to be subscribed.

@CincySteve do you have a test case we can use to reproduce this?

Does this still fail if you add

    <PublishTrimmed>false</PublishTrimmed> 

To your project file? The two biggest differences between release and debug are linked assemblies and interpreter optimizations and disabling linking is eliminates one of them. @BrzVlad have you had a chance to look at this?

Unfortunately, the only app I have that experiences the problem is a fairly big one: 40+ components, 40+ significant c# classes, etc.

@lewing I'm afraid I don't know what adding PublishTrimmed to my "project file" means. I tried to add it in several places, but it was not a recognizable component. Which specific project file do you mean?

@CincySteve in the blazor wasm specific csproj inside a property group.

@lertoo @modulardev2 if either of you have a reproduction you can share it would be very helpful.

@CincySteve While there is always the chance that something goes unexpectedly wrong somewhere, based on the stacktrace that you provided this is not a bug but rather a current limitation of the interpreter. The interpreter will fail to compile methods that are extremely large (it requires more than 32kb of local space) and this is the first situation where I hear of this happening. Fixing this is quite a bit of effort, so it wouldn't make it to 5.0. If you are over on the DotNetEvolution discord server, we can discuss it there in private and I can guide you to find which method fails to compile and confirm if this limitation is actually hit.

Maybe we should error out instead of just asserting to make it easier to find the offending method.
The JIT throws an InvalidProgram exception for some extremely large methods with the
message 'Method is too complex.'.

@BrzVlad Thanks for the help. I just restored a version of my app from 2 days ago. It does not trigger the exception. Based on a folder comparison, it looks like I made a bunch of changes, so I would appreciate your private help in DotNetEvolution to find the one (or more) that hit the limit. So I and others are clear, the problem is with a METHOD that is too big, not something else (like a class). I am registered in DotNetEvolution and have sent you a message. Thanks again.

@lertoo @modulardev2 if either of you have a reproduction you can share it would be very helpful.

Sure thing. I created a project here: https://github.com/modulardev2/ThreadException

It's simply the standard blazor web assembly/hosted project template, with the FetchData OnInitializedAsync changed to:
protected override async Task OnInitializedAsync() { Console.WriteLine(await Http.GetStringAsync("WeatherForecast")); }

It works when I run it locally, but as you can see if you go to the live site it doesn't work: https://pws.northcentralus.cloudapp.azure.com:49190/fetchdata

If it helps, the site is running on IIS on an Azure VM

@modulardev2 Thanks. Can't reproduce from VS, but it fails when it is published to a local IIS instance.

Same error here, just only in published project.

Setting this as 5.0 and blocking as this is a pretty important scenario that is broken in Blazor WASM. I can reproduce it with the following steps:

dotnet new blazorwasm

edit the Pages/FetchData.razor file to add 
    Console.WriteLine(await Http.GetStringAsync("/"));
inside of the OnInitializedAsync method

dotnet publish -c Release

dotnet serve -d .\bin\Release\net5.0\publish\wwwroot\

navigate to http://localhost:8080/ and click on the "Fetch data" tab

(note you need to install https://github.com/natemcmaster/dotnet-serve to use dotnet serve)

I also verified that this worked on 5.0-preview8, but fails on 5.0-rc1.

In my case, error occurs also in DEBUG published in Azure Webapps. So I think this is not a Release mode particularity.

So I think this is not a Release mode particularity.

Agreed. It repros with dotnet publish -c Debug as well. Force of habit that I always publish -c Release. 馃槈

Just so the discussion doesn't get too narrow, as the originator of this issue, I would like to note that I have experienced the assertion exception in both the debugger under VS and with the same app published to Azure. And, my app does not invoke Http.GetStringAsync as some who have had a similar or the same exception have.

I have tried to replicate it under .Net 5.0 RC1, but think I didn't do that properly. In any case, I will start tomorrow to incrementally change my app from the last version that worked to one that does not by comparing the changes I made between the two versions. I hope that will help.

@CincySteve I suggest opening a separate issue together with any new findings, since this one was hijacked by a separate .net 5 rc1 regression.

@lewing @mkArtakMSFT I believe we can move the Blocking-release label and 5.0 Milestone from here to the linked bug.

@SamMonoRT mono/linker doesn't have the labels, I'm not sure how it is usually handled?

This is blocking on https://github.com/mono/linker/issues/1507

@eerhardt - Leaving this open as a Blocked issue - Not an interpreter issue, update area label to area-Meta

After a lot of digging and help from @BrzVlad , I have found that he was correct in diagnosing my problem (not necessarily the others) as a method that is too large. I load some data lists in Program.cs via calls to static class methods, one of which is very large. These classes are generated by a custom utility I wrote using external data sources. I'm not sure why this started to fail only recently (this code has been running for at least 2 months, which is why I didn't think about it). And of course, the Assertion exception is a mysterious symptom. Anyway, thanks once again to @BrzVlad.

Update - the underlying linker issue has been fixed and is being backported to 5.0. Once that is merged we should be able to close this issue.

@eerhardt is there any work required on the runtime side for this issue for rc2 or GA ?

I don't believe so. To fix this we will need:

  1. The above linker change to be ported to the 5.0 branch.
  2. The new 5.0 linker to be merged into the dotnet/sdk 5.0 branch.

The changes were backported to 5.0 GA branch and merged to dotnet/sdk

Hi, I have updated to RC2 today but the error still is present.

The problem seems to be this line from a Nuget Package I'm using:
await Http.GetJsonAsync(ApiUrl + SearchTermParam(SearchTerm));

Is this Bug not fixed unit now?

The strange thing is that if I ran my application with VisualStudio and Debugging everything is working.
If I make a dotnet pusblish with "--configuration Debug" and create a docker container from the output to deploy it on my server this error occures.

@truthz03 RC2 was frozen before the fix went in. The fix will be part of 5.0 final.

Ok. Thanks. Than I will wait for it

This issue is NOT fixed. I upgrade to the latest 5 net 5 sdk. Works locally, error appears when deploying to azure on windows hosted app service.

Just for others coming here, "false " works for me to get rid of the exception

@joer33304 can you please open a new issue with the details of the problem you are encountering?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jzabroski picture jzabroski  路  3Comments

bencz picture bencz  路  3Comments

jchannon picture jchannon  路  3Comments

omajid picture omajid  路  3Comments

yahorsi picture yahorsi  路  3Comments