# Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr ************ in tid **** (SGen worker)

[dcrespo-isaac]

Android framework version

net8.0-android

Affected platform version

.NET 8.0.100, .NET 8.0.303

Description

Our Android application started to crash randomly 3 months ago when we upgraded it to .net6.
We tried to add more logging, analyze the logcat, reproduce... but all in vain.

In an attempt to stabilize the app, we have upgraded to .net8.0-android and the number of crash was significantly reduced.
This problem happens on different kind of tablets, and we excluded the idea that it could come from firmware or hardware
because they did not change and with .net framework (Xamarin) everything was running smoothly (1 crash rarely vs hundreds per day now).

Our dev and testing team (qa) are not able to reproduce the problem. Looking at the logs (SIGSEGV_Samples_logcat-with-symbols.txt), we see that all of the SIGSEGV (SEGV_MAPERR) happens on the SGen worker thread but give different backtraces.
At the end of the log file, you’ll find a SIGABRT from SGen. We’ve kept it there for reference, in case it’s related to the SIGSEGV issues.

We used dotnet-symbol to retrieve a debug version of libmonosgen-2-0.so (with symbols). Then we run ndk-stack on our
logcat to symbolize the backtraces.

Application catches nothing. So we don't have any other traces to give from it. The logcat contains the most detailled
ones we have.

FYI, we did split our crashes into 3 categories, we're not sure that they related to the SIGSEGV...
but to give you all data, the other 2 are :

• Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid ***** (|ANR-WatchDog|), pid ***** (com.isaac.onthego)
• Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid ***** (enableInternal), pid ***** (com.android.nfc)

What we tried :

• Reproducing by running our acceptance tests on the tablet
  -> Nothing happens unless we run the day long tests and it's very rare. It does not give more information than what we have in production.

• Upgrading .net version (from 8.0.100 to 8.0.303)
  -> Nothing changed.

• Revert to .Net Framework (Xamarin)
  -> We did it in order to identify if it's related to our changes or the framework. And it worked !!!
  The number of crash were back to normal (before .net6 and .net8).

• *** EDIT *** We also tried to disable trimming by settings <PublishTrimmed>false</PublishTrimmed> in all of our .csproj.
  -> Our APK was a little bit heavier (of course) and no changes in number of crashes..

What we are still probing :

• Disabling concurrency on Mono Garbage collector and change the bridge-implementation to old
  -> We’ve seen numerous issues and discussions about the stability of SGen. We are hoping that this change can make a difference, as the backtraces seem to point to a problem that could be within it. If this works, it could allow us to stay with .net8 until a fix is found.

Thank you in advance for your help. We will remain vigilant if you need more details.

Steps to Reproduce

Unfortunetaly we are unable to reproduce the problem in step by step as it appears randomly on production.

Did you find any workaround?

Currently, reverting to the .Net Framework appears to be effective for us.

Relevant log output

See attached files of the description

[grendello]

@dcrespo-isaac thanks for the logs! They universally show that the issue is somewhere in the MonoVM's GC (SGEN), so I think the issue belongs in dotnet/runtime. Would you happen to still have the logs that have SIGABRT in them? The reason I ask is that they would contain more information before the native stack trace is dumped. The information will contain the actual assertion message logged by MonoVM - and this message is crucial to understanding what's going on. If you could share these logs, or scour them for any log lines containing any assertions coming from MonoVM and paste them here, it would be very helpful. Thanks!

[akoeplinger]

@BrzVlad looks like a GC issue

[grendello]

@dcrespo-isaac Scan the logs for messages containing strings similar to * Assertion at which are tagged either with an empty string, DOTNET or a fragment of your application's ID. The message will also contain a file path which should have mono component in it.

[dcrespo-isaac]

Thank you for the triage.

I've found the logcat I had analyzed for the SIGSEGV errors. In the logcat-Assertion.txt, you'll find two samples of SIGABRT preceded by :

Assertion at /__w/1/s/src/mono/mono/metadata/object.c:4410, condition `is_ok (error)' not met, function:mono_unhandled_exception_internal, (null) assembly:System.Private.CoreLib.dll type:ArgumentNullException member:(null)

Additional notes:

• The SIGABRT assertion error is always the same, but it sometimes occurs on the ANR_WatchDog thread and other times on what appears to be the main thread com.isaac.onthego.
• The two samples show errors just after the start of the application. It’s true that some errors occur then, but others occur at different moments – sadly at random times – throughout the lifetime of the application.
• The number of SIGSEGV crashes is substantially higher than that of SIGABRT.
  -> We attempted to identify a pattern between SIGSEGV and SIGABRT, but found nothing significant. This means that they don’t precede or follow each other in any particular way.

I will continue to update the issue if I encounter any other assertion errors.

[lambdageek]

@dcrespo-isaac I don't have any insight for the SIGSEGV, but for SIGABRT - does your app have a AppDomain.CurrentDomain.UnhandledException event handler installed? the assertion on object.c:4410 looks like it's due to an unhandled null reference exception during the execution of the unhandled exception handler.

[dcrespo-isaac]

Hi @lambdageek,

First and foremost, thank you for your response. It is greatly appreciated. We have identified the origin of the SIGABRT:

• There was indeed a null reference that was triggered due to a race condition at startup.
• We discovered a setter in ANR_WatchDog that allows us to handle an ANR in our own way, rather than allowing the tool to crash our application.

Regarding this open issue, we continue to experience problems with SIGSEGV, which is the primary subject of this issue and, regrettably, the cause of the majority of our crashes.

We are currently deploying our reverted version to Xamarin, as it has proven to be significantly more stable. We will remain vigilant for any responses, fixes, or requests for additional information regarding this issue.