debug model can catch exception ,but release app crash

[292390450]

Android application type

Android for .NET (net6.0-android, etc.)

Affected platform version

vs2022 17.6.0 preview1.0 .net7

Description

my appwill initially connect to the signalr service, because the server address is misconfigured, the connection will fail and throw an exception, this exception can be caught, AppRuntime.LoginUser is not assigned its null and then a mistake in the program that does not reference the object to the instance will cause the program to crash. All null reference exceptions cause the program to crash.
the LoginUser isnull An exception is thrown

The uncomfortable thing is that it works correctly in debug mode.

Steps to Reproduce

AOT is not turned on

Did you find any workaround?

No response

Relevant log output

No response

[292390450]

This is the project property

[292390450]

This is the log of the program startup crash to me clicking to execute this method
text.txt

[292390450]

What do I do to get the program to work🫡

[grendello]

@292390450 The attached log contains Xamarin.Android messages from 4 different processes, and the native crash is from one of them - do you run several XA apps on the same device when debugging? If yes, please kill all of them instead of just the one that causes the crash.

I will need you to record another logcat of the crash, after following the steps given below:

$ adb shell setprop debug.mono.log default,assembly,mono_log_level=debug,mono_log_mask=all
$ adb logcat -G 16M
$ adb logcat -c
# Start the app here and when it crashes, wait a few seconds and then
$ adb logcat -d > log.txt

Then attach the log.txt file here, thanks!

Also, is it an Avalonia UI app?

Hi @292390450. 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.

[jonpryor]

When you say "it works correctly in debug mode", do you mean a Debug configuration build? Or when you have the debugger attached within Visual Studio?

If you mean the former -- i.e. you're debugging the app -- the reason it works when debugging is because exception handling semantics differs when the debugger is attached; see also:

• [docs] Document Exception Handling semantics #4877
• [debugger] Removing usage of mono_unhandled_exception #4927 (comment)

Usually this means that the app is less reliable when the debugger is attached, if you cross a JVM boundary when handling the exception, but that doesn't appear to be the case here.

[jonpryor]

Based on what is in text.txt, the abort messages are concerning, a'la:

signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
Abort message: 'exiting due to SIG_DFL handler for signal 11, ucontext 0x7170dccd2ac0'
    rax 0000000000000000  rbx 00000000000006d9  rcx 00007170d268a0ef  rdx 0000000000000006
    r8  00007170dccd2ac0  r9  00007170dccd2ac0  r10 00007170dccd2980  r11 0000000000000207
    r12 00000000000003c8  r13 0000000000000000  r14 00007170dccd2978  r15 00000000000006d9
    rdi 00000000000006d9  rsi 00000000000006d9
    rbp 00007170c614bc10  rsp 00007170dccd2970  rip 00007170d268a0ef
backtrace:
      #00 pc 000000000005f0ef  /apex/com.android.runtime/lib64/bionic/libc.so (abort+191) (BuildId: 605a99e654aa6ddc9848652402fc0a1d)
      #01 pc 00000000000031bc  /apex/com.android.art/lib64/libsigchain.so (art::SignalChain::Handler(int, siginfo*, void*)+1100) (BuildId: 7bf137522e4b2dcff126d555331076d8)
      #02 pc 000000000005b640  /apex/com.android.runtime/lib64/bionic/libc.so (__restore_rt+0) (BuildId: 605a99e654aa6ddc9848652402fc0a1d)
      #03 pc 000000000067d975  <anonymous:4113c000>

There are various conditions that will cause the .NET Runtime SIGABRT signal handler to execute, and after it executes we will chain to the Android SIGABRT handler, which is what allows the Android crash reporter to get involved, create tombstone files, etc.

What's concerning here is that Android appears to be crashing as part of its handling of SIGABRT, as everything in the backtrace is in Android native code (libc.so, libsigchain.so). This is weird.

@292390450: would you be able to provide a minimal repro that triggers this crash? I fear we're gonna need more investigation, and a repro will help.

[jonpryor]

@292390450: What Android target are you seeing this on?

[292390450]

@grendello is it an Avalonia UI app
This is the log of the output as you said
log.txt