Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Blazor Web Assembly call Azure Function crashes .Net 5.0 rc2 #44210

Closed
vsfeedback opened this issue Nov 3, 2020 · 24 comments · Fixed by #44305 or mono/mono#20554
Closed

Blazor Web Assembly call Azure Function crashes .Net 5.0 rc2 #44210

vsfeedback opened this issue Nov 3, 2020 · 24 comments · Fixed by #44305 or mono/mono#20554
Assignees
@javiercn
Labels
arch-wasm WebAssembly architecture area-Debugger-mono
Milestone
5.0.1

Comments

@vsfeedback
Copy link

This issue has been moved from a ticket on Developer Community.

[severity:I'm unable to use this version of Visual Studio] [regression] [worked-in:.Net 5.0 rc2]
I recreated this in a very simple pair of projects. Project 1 is a Blazor WebAssembly project. Project 2 is an Azure Function project. Only change to Blazor project was to setup CORS and add code to all Azure Function. Just go to the Fetch data page and the error will happen. The Browser window will crash in the Web Assembly code. Look at the F12 debugger on the console. See BlazorCrash.zip for project files. This seems to happen all calling to Functions. This used to work at I am blocked from using rc2 because of this.

Uncaught (in promise) RuntimeError: abort(undefined). Build with -s ASSERTIONS=1 for more info.
at abort (https://localhost:44358/_framework/dotnet.5.0.0-rc.2.20475.5.js:1:14903)
at _abort (https://localhost:44358/_framework/dotnet.5.0.0-rc.2.20475.5.js:1:105666)
at stub_debugger_agent_user_break (:wasm-function[6500]:0xf94a6)
at do_debugger_tramp (:wasm-function[3306]:0x79e23)
at interp_exec_method (:wasm-function[2155]:0x442e1)
at interp_runtime_invoke (:wasm-function[7859]:0x12ef59)
at mono_jit_runtime_invoke (:wasm-function[7344]:0x118db9)
at do_runtime_invoke (:wasm-function[3304]:0x79d37)
at mono_runtime_try_invoke (:wasm-function[629]:0x12977)
at mono_runtime_invoke (:wasm-function[7115]:0x10eb85)
abort @ dotnet.5.0.0-rc.2.20475.5.js:1
_abort @ dotnet.5.0.0-rc.2.20475.5.js:1
stub_debugger_agent_user_break @ 00ab9d9a:0xf94a6
do_debugger_tramp @ 00ab9d9a:0x79e23
interp_exec_method @ 00ab9d9a:0x442e1
interp_runtime_invoke @ 00ab9d9a:0x12ef59
mono_jit_runtime_invoke @ 00ab9d9a:0x118db9
do_runtime_invoke @ 00ab9d9a:0x79d37
mono_runtime_try_invoke @ 00ab9d9a:0x12977
mono_runtime_invoke @ 00ab9d9a:0x10eb85
mono_wasm_invoke_method @ 00ab9d9a:0x108e03
Module._mono_wasm_invoke_method @ dotnet.5.0.0-rc.2.20475.5.js:1
call_method @ dotnet.5.0.0-rc.2.20475.5.js:1
set_task_result @ dotnet.5.0.0-rc.2.20475.5.js:1
(anonymous) @ dotnet.5.0.0-rc.2.20475.5.js:1
Promise.then (async)
js_to_mono_obj @ dotnet.5.0.0-rc.2.20475.5.js:1
mono_wasm_convert_return_value @ dotnet.5.0.0-rc.2.20475.5.js:1
_mono_wasm_invoke_js_with_args @ dotnet.5.0.0-rc.2.20475.5.js:1
do_icall @ 00ab9d9a:0x194d3f
do_icall_wrapper @ 00ab9d9a:0x79dee
interp_exec_method @ 00ab9d9a:0x44ac8
interp_runtime_invoke @ 00ab9d9a:0x12ef59
mono_jit_runtime_invoke @ 00ab9d9a:0x118db9
do_runtime_invoke @ 00ab9d9a:0x79d37
mono_runtime_try_invoke @ 00ab9d9a:0x12977
mono_runtime_invoke @ 00ab9d9a:0x10eb85
mono_wasm_invoke_method @ 00ab9d9a:0x108e03
Module._mono_wasm_invoke_method @ dotnet.5.0.0-rc.2.20475.5.js:1
call_method @ dotnet.5.0.0-rc.2.20475.5.js:1
set_task_result @ dotnet.5.0.0-rc.2.20475.5.js:1
(anonymous) @ dotnet.5.0.0-rc.2.20475.5.js:1
Promise.then (async)
js_to_mono_obj @ dotnet.5.0.0-rc.2.20475.5.js:1
mono_wasm_convert_return_value @ dotnet.5.0.0-rc.2.20475.5.js:1
_mono_wasm_invoke_js_with_args @ dotnet.5.0.0-rc.2.20475.5.js:1
do_icall @ 00ab9d9a:0x194d3f
do_icall_wrapper @ 00ab9d9a:0x79dee
interp_exec_method @ 00ab9d9a:0x44ac8
interp_runtime_invoke @ 00ab9d9a:0x12ef59
mono_jit_runtime_invoke @ 00ab9d9a:0x118db9
do_runtime_invoke @ 00ab9d9a:0x79d37
mono_runtime_try_invoke @ 00ab9d9a:0x12977
mono_runtime_invoke @ 00ab9d9a:0x10eb85
mono_wasm_invoke_method @ 00ab9d9a:0x108e03
Module._mono_wasm_invoke_method @ dotnet.5.0.0-rc.2.20475.5.js:1
call_method @ dotnet.5.0.0-rc.2.20475.5.js:1
set_task_result @ dotnet.5.0.0-rc.2.20475.5.js:1
(anonymous) @ dotnet.5.0.0-rc.2.20475.5.js:1
Promise.then (async)
js_to_mono_obj @ dotnet.5.0.0-rc.2.20475.5.js:1
mono_wasm_convert_return_value @ dotnet.5.0.0-rc.2.20475.5.js:1
_mono_wasm_invoke_js_with_args @ dotnet.5.0.0-rc.2.20475.5.js:1
do_icall @ 00ab9d9a:0x194d3f
do_icall_wrapper @ 00ab9d9a:0x79dee
interp_exec_method @ 00ab9d9a:0x44ac8
interp_runtime_invoke @ 00ab9d9a:0x12ef59
mono_jit_runtime_invoke @ 00ab9d9a:0x118db9
do_runtime_invoke @ 00ab9d9a:0x79d37
mono_runtime_try_invoke @ 00ab9d9a:0x12977
mono_runtime_invoke @ 00ab9d9a:0x10eb85
mono_wasm_invoke_method @ 00ab9d9a:0x108e03
Module._mono_wasm_invoke_method @ dotnet.5.0.0-rc.2.20475.5.js:1
call_method @ dotnet.5.0.0-rc.2.20475.5.js:1
set_task_result @ dotnet.5.0.0-rc.2.20475.5.js:1
(anonymous) @ dotnet.5.0.0-rc.2.20475.5.js:1
Promise.then (async)
js_to_mono_obj @ dotnet.5.0.0-rc.2.20475.5.js:1
mono_wasm_convert_return_value @ dotnet.5.0.0-rc.2.20475.5.js:1
_mono_wasm_invoke_js_with_args @ dotnet.5.0.0-rc.2.20475.5.js:1
do_icall @ 00ab9d9a:0x194d3f
do_icall_wrapper @ 00ab9d9a:0x79dee
interp_exec_method @ 00ab9d9a:0x44ac8
interp_runtime_invoke @ 00ab9d9a:0x12ef59
mono_jit_runtime_invoke @ 00ab9d9a:0x118db9
do_runtime_invoke @ 00ab9d9a:0x79d37
mono_runtime_invoke_checked @ 00ab9d9a:0xf652
mono_runtime_try_invoke_array @ 00ab9d9a:0x10e78b
ves_icall_InternalInvoke @ 00ab9d9a:0xed487
ves_icall_InternalInvoke_raw @ 00ab9d9a:0xecf4c
do_icall @ 00ab9d9a:0x194d3f
do_icall_wrapper @ 00ab9d9a:0x79dee
interp_exec_method @ 00ab9d9a:0x44ac8
interp_runtime_invoke @ 00ab9d9a:0x12ef59
mono_jit_runtime_invoke @ 00ab9d9a:0x118db9
do_runtime_invoke @ 00ab9d9a:0x79d37
mono_runtime_try_invoke @ 00ab9d9a:0x12977
mono_runtime_invoke @ 00ab9d9a:0x10eb85
mono_wasm_invoke_method @ 00ab9d9a:0x108e03
Module._mono_wasm_invoke_method @ dotnet.5.0.0-rc.2.20475.5.js:1
call_method @ dotnet.5.0.0-rc.2.20475.5.js:1
(anonymous) @ dotnet.5.0.0-rc.2.20475.5.js:1
beginInvokeDotNetFromJS @ blazor.webassembly.js:1
h @ blazor.webassembly.js:1
e.invokeMethodAsync @ blazor.webassembly.js:1
(anonymous) @ blazor.webassembly.js:1
(anonymous) @ blazor.webassembly.js:1
(anonymous) @ blazor.webassembly.js:1
(anonymous) @ blazor.webassembly.js:1
r @ blazor.webassembly.js:1
(anonymous) @ blazor.webassembly.js:1
(anonymous) @ blazor.webassembly.js:1
(anonymous) @ blazor.webassembly.js:1
(anonymous) @ blazor.webassembly.js:1
(anonymous) @ blazor.webassembly.js:1
r @ blazor.webassembly.js:1
d @ blazor.webassembly.js:1
f @ blazor.webassembly.js:1
(anonymous) @ blazor.webassembly.js:1
(anonymous) @ blazor.webassembly.js:1
e.onGlobalEvent @ blazor.webassembly.js:1
Show 44 more frames

Original Comments

Feedback Bot on 10/25/2020, 09:14 PM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

Brett McDonald on 10/27/2020, 08:10 AM:

Is there any word on this? This is a showstopper for me.

Original Solutions

(no solutions)
@javiercn
Copy link
Member

javiercn commented Nov 3, 2020

I confirmed this to be an issue in 5.0.0.

I believe this affects CORS in general, and that the underlying cause is in the mono runtime. No matter whether the request mode was set to CORS on the request or not before being sent.

@bfmsoft
Copy link

bfmsoft commented Nov 3, 2020

What confuses me is this seems to be really straight forward thing to do with Blazor. Calling an Azure Function pretty standard from a WASM Blazor app.

@mkArtakMSFT
Copy link
Member

@javiercn should we move this to the runtime repo then? What's pending for that?

@javiercn
Copy link
Member

javiercn commented Nov 3, 2020

Request and responses look fine

image

@javiercn
Copy link
Member

javiercn commented Nov 3, 2020

There is a repro project in the associated feedback ticket

@javiercn javiercn transferred this issue from dotnet/aspnetcore Nov 3, 2020
@Dotnet-GitSync-Bot
Copy link
Collaborator

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added the untriaged New issue has not been triaged by the area owner label Nov 3, 2020
@javiercn
Copy link
Member

javiercn commented Nov 3, 2020

@lewing and @kjpou1 Can you take a look at this? It reproes on 5.0.0 RTM, so I imagine its a candidate for servicing.

@lewing lewing added the arch-wasm WebAssembly architecture label Nov 3, 2020
@lewing
Copy link
Member

lewing commented Nov 3, 2020

@thaystg can you take a look at this

@lewing lewing added this to the 5.0.1 milestone Nov 3, 2020
@thaystg
Copy link
Member

thaystg commented Nov 3, 2020

Could you please test if removing System.Diagnostics.Debugger.Break() from your code it works, it's in fetchdata.razor file. It looks like it's not implemented.

@bfmsoft
Copy link

bfmsoft commented Nov 3, 2020

Seems remove that and doesn't throw the error in Browser. Is that how it is "supposed" to handle that?

@bfmsoft
Copy link

bfmsoft commented Nov 3, 2020

I still have a problem guess I will have to figure out what it is. Thought that project recreated it.

@thaystg
Copy link
Member

thaystg commented Nov 3, 2020

No, we should implement support to System.Diagnostics.Debugger.Break().
I was just checking if this was the issue.

@thaystg
Copy link
Member

thaystg commented Nov 3, 2020

@captainsafia , does it make any sense for you?
On older versions of Blazor the generated version of fetchdata.razor doesn't generate it: System.Diagnostics.Debugger.Break() ?

@captainsafia
Copy link
Member

Nope, the default Blazor template doesn't put System.Diagnostics.Debugger.Break() anywhere in the FetchData.razor file. Below is a link the default template file.

https://github.com/dotnet/aspnetcore/blob/b1dcacabec1aeacef72c9aa2909f1cb49993fa73/src/ProjectTemplates/Web.ProjectTemplates/content/ComponentsWebAssembly-CSharp/Client/Pages/FetchData.razor#L1-L82

@bfmsoft
Copy link

bfmsoft commented Nov 3, 2020

I think it should be implemented. Use it all the time. At least a complete error or something if not supported.

@thaystg
Copy link
Member

thaystg commented Nov 3, 2020

I will implement it! Thanks.

@javiercn
Copy link
Member

javiercn commented Nov 3, 2020

@bfmsoft the original problem is that the CORS mode wasn't being set on the request options. You need to call request.SetBrowserRequestMode(RequestMode.Cors) to perform cross-origin calls.

@bfmsoft
Copy link

bfmsoft commented Nov 3, 2020

I am using:
res = await httpClient.GetAsync(funcUrl);

Are you saying I have to build request so I can set that?

@javiercn
Copy link
Member

javiercn commented Nov 3, 2020

@bfmsoft You can write a custom message handler and apply that to your httpclient instance instead

@ghost
Copy link

ghost commented Nov 4, 2020

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

@CoffeeFlux CoffeeFlux added area-Debugger-mono and removed area-VM-meta-mono untriaged New issue has not been triaged by the area owner labels Nov 4, 2020
@ghost
Copy link

ghost commented Nov 4, 2020

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

@bfmsoft
Copy link

bfmsoft commented Nov 4, 2020

@javiercn "You can write a custom message handler and apply that to your httpclient instance instead." Could you point at a sample to do that the right way in 5.0? Seems all the samples I find are years old.

@javiercn
Copy link
Member

javiercn commented Nov 4, 2020

@bfmsoft this is using HttpClientFactory

            builder.Services.AddTransient<CorsHandler>();
            builder.Services.AddHttpClient("API", c => c.BaseAddress = new Uri(builder.HostEnvironment.BaseAddress))
                .AddHttpMessageHandler<CorsHandler>();
            builder.Services.AddScoped(sp => sp.GetRequiredService<IHttpClientFactory>().CreateClient("API"));
        }
    }

    internal class CorsHandler : DelegatingHandler
    {
        protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
        {
            request.SetBrowserRequestMode(BrowserRequestMode.Cors);
            return base.SendAsync(request, cancellationToken);
        }
    }

@thaystg thaystg mentioned this issue Nov 5, 2020
Merged
@monojenkins monojenkins mentioned this issue Nov 5, 2020
Merged
monojenkins pushed a commit to monojenkins/mono that referenced this issue Nov 5, 2020
@thaystg
[wasm][debugger] Implementing support to Debugger::Break.
6855d9b 
Fixes dotnet/runtime#44210
akoeplinger pushed a commit to mono/mono that referenced this issue Nov 6, 2020
@monojenkins @thaystg
[wasm][debugger] Implementing support to Debugger::Break. (#20554)
a7c5fa2 
Fixes dotnet/runtime#44210

Co-authored-by: thaystg <thaystg@users.noreply.github.com>
@javiercn
Copy link
Member

javiercn commented Nov 6, 2020

@lewing thanks for the quick fix!

Do we need to track this issue for servicing?

@lewing lewing mentioned this issue Nov 20, 2020
Merged
@ghost ghost locked as resolved and limited conversation to collaborators Dec 6, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@javiercn javiercn

Labels
arch-wasm WebAssembly architecture area-Debugger-mono
Projects
None yet
Milestone
5.0.1
10 participants
@lewing @captainsafia @CoffeeFlux @thaystg @javiercn @jeffschwMSFT @vsfeedback @mkArtakMSFT @Dotnet-GitSync-Bot @bfmsoft