Skip to content

MONO_WASM: jit_call code generation failed in Blazor WASM project #113657

Open
Open
MONO_WASM: jit_call code generation failed in Blazor WASM project#113657
Labels
arch-wasmWebAssembly architecturearea-Codegen-Interpreter-monoos-browserBrowser variant of arch-wasm
Milestone
9.0.x

Description

@Dona278
Dona278
opened on Mar 18, 2025

Description

We have a Blazor wasm project which after upgrade to net9 (same build with net8 works well) throws this type of error during normal usage BUT ONLY in production.

MONO_WASM: jit_call code generation failed: CompileError: WebAssembly.Module(): Compiling function #4 failed: Invalid tag index: 0 @+122
Pe @ dotnet.runtime.qrl1fuqt3c.js.br:3
Qi @ dotnet.runtime.qrl1fuqt3c.js.br:3
$func96526 @ dotnet.native.pysfeifdhn.wasm.br:0x202053f
$func96521 @ dotnet.native.pysfeifdhn.wasm.br:0x201368c
$mono_jiterp_interp_entry @ dotnet.native.pysfeifdhn.wasm.br:0x201176a
$54e83e8_ctions>d__52:MoveNext___ @ 172be272:0xab
$func74358 @ dotnet.native.pysfeifdhn.wasm.br:0x19d9b84
$func12856 @ dotnet.native.pysfeifdhn.wasm.br:0x533e45
$func73323 @ dotnet.native.pysfeifdhn.wasm.br:0x19ad5aa
$func12799 @ dotnet.native.pysfeifdhn.wasm.br:0x52f942
invoke_iii @ dotnet.native.2kf7ulbwqd.js.br:8
$func12868 @ dotnet.native.pysfeifdhn.wasm.br:0x534edb
$func73343 @ dotnet.native.pysfeifdhn.wasm.br:0x19ae0a6
$func74070 @ dotnet.native.pysfeifdhn.wasm.br:0x19cefc1
invoke_viii @ dotnet.native.2kf7ulbwqd.js.br:8
$func69795 @ dotnet.native.pysfeifdhn.wasm.br:0x18efb84
$func73349 @ dotnet.native.pysfeifdhn.wasm.br:0x19ae477
$func73348 @ dotnet.native.pysfeifdhn.wasm.br:0x19ae30e
$func74046 @ dotnet.native.pysfeifdhn.wasm.br:0x19cc31b
$func12676 @ dotnet.native.pysfeifdhn.wasm.br:0x524700
$func74070 @ dotnet.native.pysfeifdhn.wasm.br:0x19cef6b
$func70116 @ dotnet.native.pysfeifdhn.wasm.br:0x18fe697
$func69659 @ dotnet.native.pysfeifdhn.wasm.br:0x18e6e41
$func69650 @ dotnet.native.pysfeifdhn.wasm.br:0x18e683b
$func69646 @ dotnet.native.pysfeifdhn.wasm.br:0x18e602c
invoke_jji @ dotnet.native.2kf7ulbwqd.js.br:8
$func69645 @ dotnet.native.pysfeifdhn.wasm.br:0x18e5cd1
$func74146 @ dotnet.native.pysfeifdhn.wasm.br:0x19d266e
$mono_wasm_execute_timer @ dotnet.native.pysfeifdhn.wasm.br:0x20f93a7
mono_wasm_schedule_timer_tick @ dotnet.runtime.qrl1fuqt3c.js.br:3
callUserCallback @ dotnet.native.2kf7ulbwqd.js.br:8
(anonymous) @ dotnet.native.2kf7ulbwqd.js.br:8Understand this errorAI
dotnet.runtime.qrl1fuqt3c.js.br:3 MONO_WASM: Disabling jiterpreter after 2 failures
dotnet.runtime.qrl1fuqt3c.js.br:3 MONO_WASM: // 2 jit call wrappers generated, blob follows //
dotnet.runtime.qrl1fuqt3c.js.br:3 MONO_WASM: // #0 === jcp_15e0c_c hasThis=true hasRet=false wasmArgTypes=
dotnet.runtime.qrl1fuqt3c.js.br:3 MONO_WASM: // #1 === jcp_13e1e_d hasThis=false hasRet=false wasmArgTypes=127
dotnet.runtime.qrl1fuqt3c.js.br:3 MONO_WASM: 0	00 61 73 6d 01 00 00 00 01 14 
dotnet.runtime.qrl1fuqt3c.js.br:3 MONO_WASM: 10	04 60 01 7f 00 60 04 7f 7f 7f 
dotnet.runtime.qrl1fuqt3c.js.br:3 MONO_WASM: 20	7f 00 60 00 00 60 02 7f 7f 00 
dotnet.runtime.qrl1fuqt3c.js.br:3 MONO_WASM: 30	02 20 05 01 69 01 30 00 03 01 
dotnet.runtime.qrl1fuqt3c.js.br:3 MONO_WASM: 40	69 01 31 00 03 01 69 01 32 00 
dotnet.runtime.qrl1fuqt3c.js.br:3 MONO_WASM: 50	00 01 69 01 33 00 02 01 6d 01 
dotnet.runtime.qrl1fuqt3c.js.br:3 MONO_WASM: 60	68 02 00 01 03 03 02 01 01 07 
dotnet.runtime.qrl1fuqt3c.js.br:3 MONO_WASM: 70	1d 02 0b 6a 63 70 5f 31 35 65 
dotnet.runtime.qrl1fuqt3c.js.br:3 MONO_WASM: 80	30 63 5f 63 00 04 0b 6a 63 70 
dotnet.runtime.qrl1fuqt3c.js.br:3 MONO_WASM: 90	5f 31 33 65 31 65 5f 64 00 05 
dotnet.runtime.qrl1fuqt3c.js.br:3 MONO_WASM: 100	0a 45 02 21 01 01 7f 06 40 20 
dotnet.runtime.qrl1fuqt3c.js.br:3 MONO_WASM: 110	01 28 00 00 20 02 28 00 04 10 
dotnet.runtime.qrl1fuqt3c.js.br:3 MONO_WASM: 120	00 07 00 10 02 10 03 20 03 41 
dotnet.runtime.qrl1fuqt3c.js.br:3 MONO_WASM: 130	01 36 02 00 0b 0f 0b 21 01 01 
dotnet.runtime.qrl1fuqt3c.js.br:3 MONO_WASM: 140	7f 06 40 20 01 28 00 00 20 02 
dotnet.runtime.qrl1fuqt3c.js.br:3 MONO_WASM: 150	28 00 04 10 01 07 00 10 02 10 
dotnet.runtime.qrl1fuqt3c.js.br:3 MONO_WASM: 160	03 20 03 41 01 36 02 00 0b 0f 
dotnet.runtime.qrl1fuqt3c.js.br:3 MONO_WASM: 170	0b 
dotnet.runtime.qrl1fuqt3c.js.br:3 MONO_WASM: // end blob //

I thought immediatly that could be related to trimming which is full for the main project and partial for library with components.
The strange thing is that even with the error the render seems to work and after some of these error during normal usage this type of error doesn't appear anymore so I ask to discord channel for any suggestion and someone told me that this is the best place to file this issue.
With other exceptions I always investigated but with this "wasm error" I don't know where to start.. any suggestion?

Reproduction Steps

I can't reproduce in local and to prepare a minimal repro starting from our huge project it will take a long time, and I don't have this time now :(

Expected behavior

No errors

Actual behavior

Throws errors during normal usage

Regression?

Since this is an old issue, I remember that the day of the upgrade to net9 the same build with net8 works well, updated to net9 sdk and nuget packages and the error appear.

Known Workarounds

No response

Configuration

dotnet version: 9.0.201
dotnet nuget packages: 9.0.3
browser: chrome and edge got errors

Other information

No response

Activity

  1. ghost added
    area-Microsoft.VisualBasic
    on Mar 18, 2025
  2. dotnet-policy-service
    added
    untriagedNew issue has not been triaged by the area owner
    on Mar 18, 2025

  3. dotnet-policy-service commented on Mar 18, 2025

    @dotnet-policy-service
    dotnet-policy-servicebot
    on Mar 18, 2025 – with Dotnet Policy Service
    Contributor

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

  4. akoeplinger
    added
    arch-wasmWebAssembly architecture
    area-Codegen-Interpreter-mono
    and removed
    area-Microsoft.VisualBasic
    on Mar 18, 2025

  5. dotnet-policy-service commented on Mar 18, 2025

    @dotnet-policy-service
    dotnet-policy-servicebot
    on Mar 18, 2025 – with Dotnet Policy Service
    Contributor

    Tagging subscribers to 'arch-wasm': @lewing
    See info in area-owners.md if you want to be subscribed.

  6. akoeplinger commented on Mar 18, 2025

    @akoeplinger
    akoeplinger
    on Mar 18, 2025
    Member

    @kg looks related to jiterpreter

  7. dotnet-policy-service commented on Mar 18, 2025

    @dotnet-policy-service
    dotnet-policy-servicebot
    on Mar 18, 2025 – with Dotnet Policy Service
    Contributor

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

  8. BrzVlad commented on Mar 18, 2025

    @BrzVlad
    BrzVlad
    on Mar 18, 2025
    Member

    So I'm assuming there is no problem with the application, right ? This log indicates that an optimization fails so the performance of the app will be worse.

  9. kg commented on Mar 18, 2025

    @kg
    kg
    on Mar 18, 2025
    Contributor

    Yes, this indicates that the jiterpreter failed and shut itself off automatically. The error indicates something went wrong with exception handling - invalid tag index 0 suggests that maybe the exception handling tag was missing? I haven't touched the EH code recently, but I believe @pavelsavara looked at it so he might have some ideas for how this could happen.

    Is there anything unusual about your project, perhaps custom C files or linked in native libraries? I'm wondering whether relinking is causing the exception handling data to go missing.

  10. Dona278 commented on Mar 18, 2025

    @Dona278
    Dona278
    on Mar 18, 2025
    Author

    @BrzVlad yes even with these errors it seems to work well.
    About performance instead: it is relative to a single piece of code or when this error occur the rest of the application will be affected?

    @kg thanks for the info!
    The project is build with:

    <WasmEnableThreads>false</WasmEnableThreads>
<WasmEnableSIMD>false</WasmEnableSIMD>
<WasmEnableExceptionHandling>false</WasmEnableExceptionHandling>

    because otherwise on some mobile devices blazor don't start.

  11. kg commented on Mar 18, 2025

    @kg
    kg
    on Mar 18, 2025
    Contributor

    The EnableExceptionHandling option is the cause of this issue, most likely. In the past I went through some effort to ensure that it would work given that option but I must have missed something.

  12. BrzVlad commented on Mar 18, 2025

    @BrzVlad
    BrzVlad
    on Mar 18, 2025
    Member

    @kg Could this error be related to the interpreter optimizing out some clauses from the method ?

  13. kg commented on Mar 18, 2025

    @kg
    kg
    on Mar 18, 2025
    Contributor

    No, the code being generated is a transition trampoline, the equivalent of jit_call_cb. The problem is that it's trying to create a 'catch' block and the type to catch is missing.

  14. lewing
    added this to the 9.0.x milestone on Mar 18, 2025

  15. kg commented on Mar 18, 2025

    @kg
    kg
    on Mar 18, 2025
    Contributor

    Please try following the instructions in https://github.com/dotnet/runtime/blob/main/docs/design/mono/jiterpreter.md#configuring-the-jiterpreter to disable specifically jiterpreter-jit-call-enabled. That should suppress this error and keep the rest of the jiterpreter working. If that doesn't work, also disable jiterpreter-interp-entry-enabled.

    This would probably look like

    <BlazorWebAssemblyRuntimeOptions>--no-jiterpreter-jit-call-enabled</BlazorWebAssemblyRuntimeOptions>

  16. akoeplinger commented on Mar 18, 2025

    @akoeplinger
    akoeplinger
    on Mar 18, 2025
    Member

    Are you sure you need the WasmEnableExceptionHandling=false? which devices hit issues with this?

  17. Dona278 commented on Mar 18, 2025

    @Dona278
    Dona278
    on Mar 18, 2025
    Author

    @akoeplinger it was surely ipad (old generation) and some android devices but to be honest the issues were old at least one or two years and different dotnet major releases so:

    1. tomorrow I can try to build and deploy without WasmEnableExceptionHandling=false and test on ipad, then
    2. thank you @kg I will try if the first step doesn't work

  18. pavelsavara commented on Mar 19, 2025

    @pavelsavara
    pavelsavara
    on Mar 19, 2025
    Member

    I believe pavelsavara looked at it so he might have some ideas for how this could happen.

    I even made changes in the Net10 about the way how we lift exception tag ___cpp_exception from emscripten.

    We (still) only get the tag exported when WasmEnableExceptionHandling is true. And my change didn't change that conditional.

    Does ___cpp_exception symbol make sense even when WasmEnableExceptionHandling=false ?
    If not, then jiterp should not be using it either.

    If ___cpp_exception makes sense with -fexceptions too, we should drop the condition on the EXPORT_EXCEPTION_HANDLING_HELPERS/EmccExportedFunction.

    Note that WasmEnableExceptionHandling=false triggers re-link.

  19. pavelsavara
    added
    os-browserBrowser variant of arch-wasm
    and removed
    untriagedNew issue has not been triaged by the area owner
    on Mar 19, 2025

  20. Dona278 commented on Mar 19, 2025

    @Dona278
    Dona278
    on Mar 19, 2025
    Author

    I just deployed a build without WasmEnableExceptionHandling=false and I didn't have issues on old mobile devices (on which I was able to do the tests regards issue which I mentioned with that flag) and the jit error seems to not appear anymore.
    I think for dotnet the problem should be solved, but for now it's fine for me, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    arch-wasmWebAssembly architecturearea-Codegen-Interpreter-monoos-browserBrowser variant of arch-wasm

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions