simple MAUI application that is obfuscated and targeted for iOS platform crashes in Interpreter mode

[SatishDCelestial]

Description

I have a simple MAUI app targeting iOS platform. The app works fine when interpreter mode is turned off, but crashes when it is turned on. This makes me believe that the interpreter mode is chocking on some of the IL instructions which work normally in a non-interpreter mode.

Additional information : The app has been obfuscated using preemptive Dotfuscator tool

Steps to Reproduce

1. build the sample maui app.
2. obfuscate using preemptive dotfuscator. (license and other details can be provided as necessary)
3. deploy to an ios device
4. click button . observe crash
5. remove " UseInterpreter - true" from the project configuration
6. build, obfuscate and deploy to ios
7. Click the button, application doesn't crash

Link to public reproduction project repository

https://github.com/SatishDCelestial/dotnetmauibug

Version with bug

8.0.3 GA

Is this a regression from previous behavior?

No, this is something new

Last version that worked well

Unknown/Other

Affected platforms

iOS

Affected platform versions

No response

Did you find any workaround?

Not using interpreter mode is the only workaround and it is not acceptable to the user.

Relevant log output

No response

[github-actions[bot]]

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Open similar issues:

• iOS Release build crashing. (#22173), similarity score: 0.80

Closed similar issues:

• error: Failed to load AOT module 'Microsoft.Maui.Graphics' while running in aot-only mode (#13882), similarity score: 0.81
• MAUI ios app not working/crashing after deployed to Testflight (#19026), similarity score: 0.80
• aot-runtime.c:1579, condition `data' not met (#20657), similarity score: 0.77
• mono_aot_corlib_init_method_gshared_mrgctx (#18425), similarity score: 0.76

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[Rajnikant-Civica]

@SatishDCelestial I am also working on obfuscation using the Preemptive Dotfuscator tool. Are you able to setup Dotfuscator successfully on your MacOS? I am getting some errors.

[SatishDCelestial]

Hi @Rajnikant-Civica , I have not setup preemptive for mac. I was running Dotfuscator through windows on a Sample MAUI app targeting iOS | ARM64

[Rajnikant-Civica]

@SatishDCelestial so are you deploying your sample App in iPhone/Physical Device?

[SatishDCelestial]

Both emulator and physical device

[Rajnikant-Civica]

@SatishDCelestial did you try this?

<PropertyGroup Condition="$(TargetFramework.Contains('-ios'))">
    <!-- <UseInterpreter>true</UseInterpreter> -->
    <MtouchInterpreter>all</MtouchInterpreter>
</PropertyGroup>

[SatishDCelestial]

@Rajnikant-Civica , Yes we did try using <MtouchInterpreter>all</MtouchInterpreter> Unfortunately the app still crashed.

[drasticactions]

@rolfbjarne Would you know more about this?

[rolfbjarne]

Link to public reproduction project repository

SatishDCelestial/dotnetmauibug

I get a 404, is it a private repo?

In any case, this is probably an incompatibility between PreEmptive Dotfuscator and Mono / the interpreter. Where the bug is really depends on whether PreEmptive Dotfuscator produces invalid IL or not (some obfuscators create invalid IL that just happens to work).

[SatishDCelestial]

Hi @rolfbjarne ,

My bad on the repository, Can you please try now ?

I have attached IL after obfuscation for working case and a not working case. (https://github.com/SatishDCelestial/dotnetmauibug/tree/master/IL%20Files)

Essentially we observed that when we use a ?. (Null conditional) in the code, the resulting IL (after obfuscation) is choking the mono interpreter. When we replace ?. with ( != null && ) there are no issues

Can you please share some insights on what part of IL caused the interpreter to crash in the failing case?

Thanks

[rolfbjarne]

I can't see anything obviously wrong about the IL, so I'm moving this to dotnet/runtime, where the interpreter code is.

[dotnet-policy-service[bot]]

Tagging subscribers to 'os-ios': @vitek-karas, @kotlarmilos, @ivanpovazan, @steveisok, @akoeplinger See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service[bot]]

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

[ivanpovazan]

@BrzVlad can this be: https://github.com/dotnet/runtime/pull/105477

[BrzVlad]

This issue appears to be the same to the one that https://github.com/dotnet/runtime/pull/68855 was fixing, being caused by weird control flow. I plan to do some refactorings in the area and hopefully simplify that PR. The fix will probably be too risky to backport for .net9.

[SatishDCelestial]

Thank you, @BrzVlad. This issue is quite important for us to have resolved. Do you have any timelines in mind for when the fix might be available?

[BrzVlad]

I expect to be able to fix this relatively soon, in the following days, however it is not clear when the fix would be published. It will surely be part of .NET10 release, with the first preview around february. Assuming we would decide to backport for .NET9, depending on the complexity of the fix, it would be available in about 2 months.

[SatishDCelestial]

Thank you for the response @BrzVlad , We would wait for the decision on whether or not this fix would be part of .NET 9.

[Lukazo0]

Thank you Vlad, @BrzVlad. Please take into consideration that this issue affects us and our customers. Hence, we'd be glad to see this issue fast-tracked, if possible, of course 😊