[.NET 8] Android crash at xamarin::android::Helpers::abort_application
#8673
Comments
akravch
added
Area: App Runtime
|
@akravch it's not a crash, but a deliberate termination of the application in reaction to some unrecoverable error. The debugger should definitely not be part of the trace in a release app. JIT in the stack trace is not unusual, in and of itself, but this trace appears to point to a problem with initialization of some managed class. The unhandled exception may be thrown from a static constructor (either user provided or generated by the compiler). Alas, without at least the name of the class that fails to initialize and the exception that's actually thrown, we can't do much about it. Can you provide information about what devices and Android versions the crashes occur? Is there a pattern to them? I don't see any direct calls to @lambdageek any idea how |
grendello
added
need-info
|
Thanks for the quick reply. Sure, here is a random set of the devices/OSs from this crash group:
|
microsoft-github-policy-service
bot
added
need-attention
|
@akravch do you have the |
@grendello no, it's not set explicitly to anything. I have just checked the detailed build logs and I see that it is not getting set to |
|
@akravch thanks! Are you able to get the application crash tombstones from Google? If you can, they may contain fragments of logcat output which is what we need to even start looking for the cause :( If the tombstones aren't available, can you see if any of the crashes contain the actual abort signal message (look for The traces you get should have addresses in them, would you be able to pick one that has the longest trace and paste here? To accompany it, I'd need you to extract the Additionally, there's something weird in your trace, namely the |
grendello
added
need-info
|
@grendello we were able to get a very limited logcat, and from the tombstone I see that the signal is There is also no Attaching a zip with the |
microsoft-github-policy-service
bot
added
need-attention
|
I've just realized why we see The assertion ends up logged by us, then, since its a fatal error, the app aborts by calling the Looks like it's a MonoVM runtime issue. @lambdageek would you mind taking a look, or delegating to whomever could look into it? Thanks! |
grendello
removed
the
need-attention
|
@akravch is there any output tagged with |
No, unfortunately, not a single line. Are these logs enabled by default in release builds though? I'm not really familiar with how to configure verbosity for this kind of logs, but if someone here knows a way to make sure they will remain enabled, we could try it in our next release. |
This is a known regression in .NET SDK 8.0.1. See dotnet/runtime#96804 it will be fixed in .NET SDK 8.0.2 (coming in February). As a temporary workaround you can force the SDK to use the runtime from 8.0.0 - see dotnet/runtime#96804 (comment) for instructions. |
|
@lambdageek thanks for the idea. Although, we did try to release our app on 8.0.100 a few weeks back, and we still had these I think we'll try to release on 8.0.100 once again and see if we'll be able to get more logs. |
note that once 8.0.101 was released, installing a .NET workload will pick up the 8.0.1 runtime pack; just changing things in <Target Name="UpdateRuntimePackVersion" BeforeTargets="ProcessFrameworkReferences">
<ItemGroup>
<KnownRuntimePack Condition="%(RuntimePackLabels) == 'Mono'" LatestRuntimeFrameworkVersion="8.0.0" />
</ItemGroup>
</Target> |
|
Still seeing this on 8.0.200, although much less and with a slightly different stacktrace: |
|
Also experiencing a similar issue, might be related to dotnet/maui#22812. Using latest Android 34.0.113, was also occurring on previous version. Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 3202 (.NET TP Worker), pid 2403 (o.adelaidemetro) |
|
@dmariogatto in your case this appears to be the cause: Are you running a Debug build on device by chance? |
|
@grendello Interesting... it's a release build deployed from Visual Studio. Getting Fatal signal 6 (SIGABRT) from GooglePlay builds and was trying to add some extra logging locally. |
|
@dmariogatto it might be that the trimmer removes something it shouldn't have (it's just a wild guess). The message above comes from this code, but it doesn't mean Mono encountered a, well, Type type it doesn't know, but that the Type isn't specified (the Also, to record the most useful log for us, please issue these commands from the VS dev prompt before you repro the crash: > adb shell setprop debug.mono.log default,assembly,mono_log_level=debug,mono_log_mask=all
> adb logcat -G 64M
> adb logcat -c
rem Cause the app to crash here and after it does so, wait 2-3 seconds and:
> adb logcat -d > logcat.txt |
|
@grendello Attached is the logcat with the settings asked for, this is for the Release build from VS with Trimming/AOT enabled. I will also try without trimming and report back. |
|
@dmariogatto thanks for the log! Alas, Android this time swallowed the abort message and the context I was hoping for isn't there :(. Could you try logging the crashes with the same procedure until you can find the Also, could you extract |
|
@dmariogatto I also noticed that you appear to be making a HTTP request on the main thread of the application. This is, in general, inadvisable but in our case it not only throws a connection exception, but also might be causing Android to drop some log messages, and also causes this message to be logged: |
|
@grendello Thank you for looking at the log! Sorry to ask a tech support question but, how do I get it off the main thread? Essentially the view models will make an async call into a service after which a HTTP request will be made using configure await false. Although not the same repo it's the same pattern as this app. Attached is the |
|
@dmariogatto In your case it appears the actual request is made on the main thread and it appears to be a 100% Java one: So perhaps it's a component you use that's not initiated directly from the managed code? |
|
@grendello That specific call, Interesting point though on async/await & requests. |
|
The symbolicated SIGABRT stack trace is as follows:
Especially interesting is frame /* This has to be variance aware since imt_method can be from an interface that vt->klass doesn't directly implement */
interface_offset = mono_class_interface_offset_with_variance (vt->klass, imt_method->klass, &variance_used);
if (interface_offset < 0)
g_error ("%s doesn't implement interface %s\n", mono_type_get_name_full (m_class_get_byval_arg (vt->klass), MONO_TYPE_NAME_FORMAT_IL), mono_type_get_name_full (m_class_get_byval_arg (imt_method->klass), MONO_TYPE_NAME_FORMAT_IL))And, indeed, while we don't have the So it would look like trimmer removing some required interface method implementations from the above type, I think. |
Can you perform the check from a separate thread?
I have a general tendency to avoid comfortable "black box" code... :) |
|
This issue still persists. |
|
@akravch As per this comment, it's probably trimmer removing some type and you need to find what that is. The details in the aforementioned comment should help you in this. Also, as asked here, I wonder if you could test the messaging platform call on a separate thread. |
|
Hi @akravch. Due to inactivity, we will be closing this issue. Please feel free to re-open this issue if the issue persists. For enhanced visibility, if over 7 days have passed, please open a new issue and link this issue there. Thank you. |
|
@grendello I think you may be referring to the other issue, the one that @dmariogatto is experiencing. Unfortunately, in my case I don't have such a detailed logcat, it's hard to say if it's related to some interface not being implemented. Also, now as we have more crash reports in our crash reporting system, it looks like this is happening more often on older Android versions (9 and below). A few crash reports have stdout/stderr attached with a single line: So this can probably be a crash in a web view. |
Android application type
.NET Android (net7.0-android, net8.0-android, etc.)
Affected platform version
.NET 8.0.101, Android workload 34.0.52, Android NDK 26.1.10909125
Description
We are getting a lot of native crashes in production that we don't have on Xamarin. Here is the top 1 crash stack trace:
Unfortunately, we don't have any ADB logs or a repro and we only see it in production.
We publish our application in AOT and, obviously, release configuration, so I'm also a little concerned about the
jitanddebuggerin the stack trace - not sure if it's expected or something went wrong with our build process too.Can anyone provide their thought on this issue, possible workarounds, etc.?
Steps to Reproduce
No repro, only getting crash reports from production.
Did you find any workaround?
No response
Relevant log output
No response
The text was updated successfully, but these errors were encountered: