Search Issue Tracker

Third Party Issue

Votes

2

Found in

6000.0.56f1

6000.2.1f1

6000.3.0a5

6000.4.0a1

Issue ID

UUM-114402

Regression

No

Crash on il2cpp::vm::Class::Init in the Player when handling FileNotFoundException in cascading catch blocks in async method

-

Reproduction steps:
1. Open the attached “IN-111273.zip” project
2. Go to Project Settings > Player
3. Make sure Scripting Backend is set to IL2CPP
4. Build and Run the project
5. Observe the built Player

Expected result: The Player does not crash
Actual result: The Player instantly crashes

Reproducible with: 2022.3.65f1, 6000.0.56f1, 6000.2.1f1, 6000.3.0a5

Reproducible on: Windows 10 (user reported), Windows 11
Not reproducible on: no other environment tested

Notes:
- The crash does not happen if the file "testfile.txt" exists on the persistent data path
- Does not reproduce with Mono Scripting Backend

First few lines of the stack trace:
0x00007FFA5C9F6B37 (GameAssembly) [C:\Program Files\Unity\6000.0.56f1_9c7b5e468860_x64\Data\il2cpp\libil2cpp\vm\Class.cpp:1592] il2cpp::vm::Class::Init
0x00007FFA5C9F7D13 (GameAssembly) [C:\Program Files\Unity\6000.0.56f1_9c7b5e468860_x64\Data\il2cpp\libil2cpp\vm\Class.cpp:645] il2cpp::vm::Class::IsAssignableFrom
0x00007FFA5DFE51D9 (GameAssembly) [C:\UsersProjects\IN-111273_empty\Library\Bee\artifacts\WinPlayerBuildProgram\il2cppOutput\cpp\Assembly-CSharp.cpp:984] U3CReadFileAsyncU3Ed__2_MoveNext_m8F73F78B56C4504D1530DEFF1C7205403E99F9A9$catch$2
0x00007FFA5CA37AC0 (GameAssembly) [D:\a\_work\1\s\src\vctools\crt\vcruntime\src\eh\amd64\handlers.asm:98] _CallSettingFrame_LookupContinuationIndex
0x00007FFA5CA369CB (GameAssembly) [D:\a\_work\1\s\src\vctools\crt\vcruntime\src\eh\frame.cpp:1439] __FrameHandler4::CxxCallCatchBlock
0x00007FFBA8366296 (ntdll) RtlCaptureContext2

  1. Resolution Note:

    This issue is cause by a bug in the MSVC compiler that has been reported to Microsoft:
    https://developercommunity.visualstudio.com/t/MSVC-Ox-Optimizer-Incorrectly-Handles-C/10975201

    The customer project contained an async method with a using statement and multiple catch blocks.

    async method
    {
    try
    using {}
    catch
    catch
    }

    This expands to nested try/catch/finally blocks like this:

    method
    {
    try // from async
    try // original try
    try // for using
    finally // dispose
    catch // original try
    catch // original try
    catch // from async
    }

    To avoid the bug, refactor the code to avoid nested try/catch blocks.

    async innerMethod
    {
    using {}
    }

    async method
    {
    try
    await innerMethod()
    catch
    catch
    }

Log in to vote on this issue

Add comment

Log in to post comment

All about bugs

View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.

Latest issues

See all new issues