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

[CincySteve]

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

[mkArtakMSFT]

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

[dantronik-bugreporting]

I am getting the same error with .NET 5.0 RC1. Here's the error message:

[modulardev2]

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

[Bob-HL]

Same issue here with RC1

[modulardev2]

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();

[Bob-HL]

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.

[ghost]

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.

[dantronik-bugreporting]

@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.

[CincySteve]

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.

[CincySteve]

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.

[CincySteve]

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

[mkArtakMSFT]

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

[ghost]

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

[mkArtakMSFT]

@eerhardt this seems to be caused by Linker

[ghost]

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

[eerhardt]

Looks like this assert is failing:

runtime/src/mono/mono/metadata/threads.c

Line 354 in dbc2d36

g_assert (new_val >= 0);

cc @lewing

[lewing]

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

[lewing]

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?

[CincySteve]

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

[CincySteve]

@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?

[lewing]

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

[lewing]

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

[BrzVlad]

@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.

[lewing]

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

This is blocking on dotnet/linker#1507

[SamMonoRT]

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

[CincySteve]

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.

[eerhardt]

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.

[Anipik]

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

[eerhardt]

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.

[marek-safar]

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

[truthz03]

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.

[lewing]

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

[truthz03]

Ok. Thanks. Than I will wait for it

[joer33304]

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.

[joer33304]

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

[lewing]

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