@grendello do we need any additional info to investigate this?

@dellis1972 someone from the Runtime team needs to look at it, however a full log would be a good thing to have.

@jeromelaban would you mind recording and attaching the crash log using instructions below?

$ adb shell setprop debug.mono.log default,assembly,mono_log_mask=all,mono_log_level=debug
$ adb logcat -G 16M
$ adb logcat -c
# Run the app here and after it crashes, do
$ adb logcat -d > log.txt

Hi @jeromelaban. We have added the "need-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

Here's the log:
log.txt

@jeromelaban hm, I spotted something interesting in your log above:

09-07 10:03:33.957  2929  2929 V Mono    : AOT: FOUND method System.OutOfMemoryException:.ctor (string) [0x79886bd360 - 0x79886bd3c4 0x798864fa07]
09-07 10:03:33.957  2929  2929 V Mono    : AOT NOT FOUND: (wrapper runtime-invoke) <Module>:runtime_invoke_void__this___object (object,intptr,intptr,intptr).
09-07 10:03:33.957  2929  2929 V Mono    : AOT: FOUND method System.Exception:.cctor () [0x79886c4b60 - 0x79886c4bc4 0x798864fbef]
09-07 10:03:33.957  2929  2929 V Mono    : AOT NOT FOUND: (wrapper runtime-invoke) object:runtime_invoke_void (object,intptr,intptr,intptr).
09-07 10:03:33.957  2929  2929 F .ui.demo.canar: * Assertion at /Users/builder/jenkins/workspace/archive-mono/2020-02/android/release/mono/mini/tramp-arm64.c:52, condition `((ins >> 24) & 0x1f) == 0x10' not met
--------- beginning of crash
09-07 10:03:33.957  2929  2929 F libc    : Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 2929 (.ui.demo.canary), pid 2929 (.ui.demo.canary)

It looks like the runtime asserts when OutOfMemoryException is being constructed?

Definitely looks that way, though I don't believe we're doing anything with OutOfMemoryException.

It seems it happens when the Mono runtime creates a default OutOfMemoryException instance very early in the startup sequence, to stash it for potential further use.

@lambdageek thinks it might have to do with an old issue when the compiler or assembler output Thumb instructions instead of non-Thumb and the runtime didn't know how to process them.

@jeromelaban would you be able to test the app without AOT enabled? Just to see if it crashes then.

@grendello the application works properly without AOT.

@jeromelaban thanks, it most likely confirms @lambdageek's theory

@jeromelaban so, we already fixed the issue in e1f2198, you would have to update to XA 17.3 to get the fix though.

@grendello Thanks for the update. Would you know when (or for which VS release) is it slated to be released?

@jeromelaban I think it's released for VS 2022 right now, you can also download the package here https://github.com/xamarin/xamarin-android#current

Ok, so if it's released (Hosted Agents are using 17.3.32825.248) it would mean that it's a different issue?

@jeromelaban to be honest, I don't know what version of XA shipped with that version of VS - it should be XA 13 which contains the fix, but I can't tell from the manifest you linked to if this is the case

According to the list of tags under the commit, v13.0.99.36 v13.0.99.18 v13.0.0.0 v12.3.99.95 v12.3.99.58 should have the fix

I checked in VS 2022 17.3.0 Preview 5.0, and it contains XA 13.0.0.0

@jeromelaban would you be able to obtain a binlog of the CI build? We would be able to check what arguments are passed to the native linker when AOT-ing

Of course, here's one: 7352-build.zip

@jeromelaban I see your build enables LLVM - this will cause the AOT task to not pass the --no-relax flag to the linker, which will eventually cause the issue. Can you try disabling LLVM to see if this is really the case?

Sure! It'll take me a few hours, I'll let you know.

@grendello Indeed, without LLVM yet with Profiled AOT enabled, the build is working properly.

@jeromelaban until #6901 is merged and released, you'll need to keep LLVM disabled. Glad that it works though :)

@jeromelaban since we addressed the original problem, I will close the issue and we can revisit enabling LLVM once #6901 is merged and you can test with it.

FWIW, I discovered this thread after having the same problem on an existing pipeline, and I can confirm that disabling LLVM solved the issue.

It's also worth noting that disabling LLVM slightly increases the package size (in our cases at least).

Android LLVM crashes might be fixed with dotnet/runtime#74991, dotnet/runtime#75261 and dotnet/runtime#74674 backported to release\7.0 -- these should be included in RC2

I have the same error, but there is no mention about AOT or LLVM.
this is my device log
device log.txt

This only happens when I build using appcenter. when I build using VS 2022 my app works fine

@Alex-Dobrynin Two things that you should check, just in case:

• Does AppCenter use a different build configuration (e.g. you build using Debug and AppCenter using Release)? The EnableLLVM option is usually enabled for Release, but not for Debug.
• Does AppCenter set the EnableLLVM param when compiling? (You can pass the parameter to msbuild to ignore what's in the csproj file). If it wasn't for this bug, EnableLLVM should be enabled for Release builds, so it wouldn't surprise me if AppCenter added some default params. to msbuild, and this was one of them.

@salgiza this is my proj settings

VS 2022 17.3.4

appcenter uses the same config but it uses this version of XA

When I change proj settings target framework to 12 android and change in appcenter version of XA to 12.3 it works well

@Alex-Dobrynin under "AOT Compilation", uncheck the "Use LLVM Optimizing Compiler" option. If it's the same bug that we've talked about in this thread, that's the option that caused the issue to appear.

@salgiza then why built by VS it is working? LLVM is on

@Alex-Dobrynin no idea, but it's worth giving it a shot. If it stills fails compiling after you disable that option, though, that would mean that, even though the resulting error is the same, you might have found a different bug.