"Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)" native fault during C# exception handling on ARM64 devices

[bencat86]

Steps to Reproduce

1. Debug app on device
2. App deploys
3. App tries to launch but crashes immediately

Expected Behavior

No crash

Actual Behavior

App crashes immediately when trying to debug on target device.

Version Information

Microsoft Visual Studio Enterprise 2019
Version 16.1.0
VisualStudio.16.Release/16.1.0+28917.181
Microsoft .NET Framework
Version 4.7.03190

Installed Version: Enterprise

Visual C++ 2019   00435-60000-00000-AA300
Microsoft Visual C++ 2019

ADL Tools Service Provider   1.0
This package contains services used by Data Lake tools

Application Insights Tools for Visual Studio Package   9.1.00429.1
Application Insights Tools for Visual Studio

ASP.NET and Web Tools 2019   16.1.429.50124
ASP.NET and Web Tools 2019

ASP.NET Web Frameworks and Tools 2019   16.1.429.50124
For additional information, visit https://www.asp.net/

Azure App Service Tools v3.0.0   16.1.429.50124
Azure App Service Tools v3.0.0

Azure Data Lake Node   1.0
This package contains the Data Lake integration nodes for Server Explorer.

Azure Data Lake Tools for Visual Studio   2.3.9000.0
Microsoft Azure Data Lake Tools for Visual Studio

Azure Functions and Web Jobs Tools   16.1.429.50124
Azure Functions and Web Jobs Tools

Azure Stream Analytics Tools for Visual Studio   2.3.9000.0
Microsoft Azure Stream Analytics Tools for Visual Studio

C# Tools   3.1.0-beta4-19266-03+9d80dea7fe1b14043b9b2ac4d0b59ed26f508742
C# components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Common Azure Tools   1.10
Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.

Extensibility Message Bus   1.1.77 (master@24013d5)
Provides common messaging-based MEF services for loosely coupled Visual Studio extension components communication and integration.

Fabric.DiagnosticEvents   1.0
Fabric Diagnostic Events

IntelliCode Extension   1.0
IntelliCode Visual Studio Extension Detailed Info

JetBrains ReSharper Ultimate 2019.1.1   Build 191.0.20190501.122851
JetBrains ReSharper Ultimate package for Microsoft Visual Studio. For more information about ReSharper Ultimate, visit http://www.jetbrains.com/resharper. Copyright © 2019 JetBrains, Inc.

Microsoft Azure HDInsight Azure Node   2.3.9000.0
HDInsight Node under Azure Node

Microsoft Azure Hive Query Language Service   2.3.9000.0
Language service for Hive query

Microsoft Azure Service Fabric Tools for Visual Studio   2.5
Microsoft Azure Service Fabric Tools for Visual Studio

Microsoft Azure Stream Analytics Language Service   2.3.9000.0
Language service for Azure Stream Analytics

Microsoft Azure Stream Analytics Node   1.0
Azure Stream Analytics Node under Azure Node

Microsoft Azure Tools   2.9
Microsoft Azure Tools for Microsoft Visual Studio 0x10 - v2.9.20419.2

Microsoft Continuous Delivery Tools for Visual Studio   0.4
Simplifying the configuration of Azure DevOps pipelines from within the Visual Studio IDE.

Microsoft JVM Debugger   1.0
Provides support for connecting the Visual Studio debugger to JDWP compatible Java Virtual Machines

Microsoft Library Manager   1.0
Install client-side libraries easily to any web project

Microsoft MI-Based Debugger   1.0
Provides support for connecting Visual Studio to MI compatible debuggers

Microsoft Visual C++ Wizards   1.0
Microsoft Visual C++ Wizards

Microsoft Visual Studio Tools for Containers   1.1
Develop, run, validate your ASP.NET Core applications in the target environment. F5 your application directly into a container with debugging, or CTRL + F5 to edit & refresh your app without having to rebuild the container.

Microsoft Visual Studio VC Package   1.0
Microsoft Visual Studio VC Package

Mono Debugging for Visual Studio   16.1.1 (2473f22)
Support for debugging Mono processes with Visual Studio.

NuGet Package Manager   5.1.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit https://docs.nuget.org/

ProjectServicesPackage Extension   1.0
ProjectServicesPackage Visual Studio Extension Detailed Info

ResourcePackage Extension   1.0
ResourcePackage Visual Studio Extension Detailed Info

ResourcePackage Extension   1.0
ResourcePackage Visual Studio Extension Detailed Info

Snapshot Debugging Extension   1.0
Snapshot Debugging Visual Studio Extension Detailed Info

SQL Server Data Tools   16.0.61904.23160
Microsoft SQL Server Data Tools

ToolWindowHostedEditor   1.0
Hosting json editor into a tool window

TypeScript Tools   16.0.10506.2004
TypeScript Tools for Microsoft Visual Studio

Visual Basic Tools   3.1.0-beta4-19266-03+9d80dea7fe1b14043b9b2ac4d0b59ed26f508742
Visual Basic components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Visual F# Tools 10.4 for F# 4.6   16.1.0-beta.19253.3+42526fe359672a05fd562dc16a91a43d0fe047a7
Microsoft Visual F# Tools 10.4 for F# 4.6

Visual Studio Code Debug Adapter Host Package   1.0
Interop layer for hosting Visual Studio Code debug adapters in Visual Studio

Visual Studio Tools for Containers   1.0
Visual Studio Tools for Containers

Visual Studio Tools for Kubernetes   1.0
Visual Studio Tools for Kubernetes

VisualStudio.Mac   1.0
Mac Extension for Visual Studio

Xamarin   16.1.0.542 (d16-1@68b985244)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.

Xamarin Designer   16.1.0.418 (remotes/origin/d16-1@5b958bb10)
Visual Studio extension to enable Xamarin Designer tools in Visual Studio.

Xamarin Templates   16.2.112 (4db4af4)
Templates for building iOS, Android, and Windows apps with Xamarin and Xamarin.Forms.

Xamarin.Android SDK   9.3.0.22 (HEAD/8e7764fdf)
Xamarin.Android Reference Assemblies and MSBuild support.
    Mono: mono/mono/2018-08@3cb36842fc4
    Java.Interop: xamarin/java.interop/d16-1@5ddc3e3
    LibZipSharp: grendello/LibZipSharp/d16-1@44de300
    LibZip: nih-at/libzip/rel-1-5-1@b95cf3f
    ProGuard: xamarin/proguard/master@905836d
    SQLite: xamarin/sqlite/3.27.1@8212a2d
    Xamarin.Android Tools: xamarin/xamarin-android-tools/d16-1@acabd26


Xamarin.iOS and Xamarin.Mac SDK   12.10.0.153 (750a879)
Xamarin.iOS and Xamarin.Mac Reference Assemblies and MSBuild support.

Log File

=================================================================
	Native Crash Reporting
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

=================================================================
	Basic Fault Adddress Reporting05-22 15:17:13.732 E/mono-rt (18283): /proc/self/maps:

=================================================================
Memory around native instruction pointer (0x7d29637678):0x7d29637668  00 1c 40 b9 c0 03 5f d6 fd 7b bf a9 fd 03 00 91  ..@..._..{......
0x7d29637678  08 20 40 b9 a8 00 c8 37 88 01 e0 37 00 00 40 f9  05-22 15:17:13.732 E/mono-rt (18283): 12c00000-12d40000 rw-p 00000000 00:01 19702                              /dev/ashmem/dalvik-main space (region space) (deleted)

. @....7...7..@.
0x7d29637688  fd 7b c1 a8 c0 03 5f d6 60 08 00 b0 01 0a 00 f0  .{...._.`.......
0x7d29637698  03 0a 00 f0 00 24 06 91 21 80 08 91 63 8c 0a 91  .....$..!...c...

No native Android stacktrace (see debuggerd output).

=================================================================
	Managed Stacktrace:
=================================================================
	  at <unknown> <0xffffffff>
	  at WP1_Tablet.Shared.App:.ctor <0x00087>
	  at WP1_Tablet.Droid.MainActivity:OnCreate <0x008a3>
	  at Android.App.Activity:n_OnCreate_Landroid_os_Bundle_ <0x000ef>
	  at Android.Runtime.DynamicMethodNameCounter:7 <0x00027>
	  at Android.Runtime.DynamicMethodNameCounter:7 <0x000cf>
=================================================================05-22 15:17:13.732 E/mono-rt (18283): 12d40000-1b500000 ---p 00140000 00:01 19702                              /dev/ashmem/dalvik-main space (region space) (deleted)

05-22 15:17:13.732 E/mono-rt (18283): 1b500000-1b7c0000 ---p 08900000 00:01 19702                              /dev/ashmem/dalvik-main space (region space) (deleted)
05-22 15:17:13.732 E/mono-rt (18283): 1b7c0000-1b800000 rw-p 08bc0000 00:01 19702                              /dev/ashmem/dalvik-main space (region space) (deleted)
05-22 15:17:13.732 E/mono-rt (18283): 1b800000-1e0c0000 ---p 08c00000 00:01 19702                              /dev/ashmem/dalvik-main space (region space) (deleted)
05-22 15:17:13.732 E/mono-rt (18283): 1e0c0000-52c00000 rw-p 0b4c0000 00:01 19702                              /dev/ashmem/dalvik-main space (region space) (deleted)
05-22 15:17:13.732 E/mono-rt (18283): 70b7d000-70b92000 rw-p 00000000 fd:01 442539                             /data/dalvik-cache/arm64/system@[email protected]
05-22 15:17:13.732 E/mono-rt (18283): 70b92000-70b93000 rw-p 00000000 fd:01 442542                             /data/dalvik-cache/arm64/system@[email protected]
05-22 15:17:13.732 E/mono-rt (18283): 70b93000-70b95000 rw-p 00000000 fd:01 442543                             /data/dalvik-cache/arm64/system@[email protected]
05-22 15:17:13.732 E/mono-rt (18283): 70b95000-70dc3000 rw-p 00000000 fd:01 442546                             /data/dalvik-cache/arm64/system@[email protected]
05-22 15:17:13.732 E/mono-rt (18283): 70dc3000-70e88000 rw-p 00000000 fd:01 442551                             /data/dalvik-cache/arm64/system@[email protected]
05-22 15:17:13.732 E/mono-rt (18283): 70e88000-70ed2000 rw-p 00000000 fd:01 442555                             /data/dalvik-cache/arm64/system@[email protected]
05-22 15:17:13.732 E/mono-rt (18283): 70ed2000-70efe000 rw-p 00000000 fd:01 442557                             /data/dalvik-cache/arm64/system@[email protected]
05-22 15:17:13.732 E/mono-rt (18283): 70efe000-70f2f000 rw-p 00000000 fd:01 442558                             /data/dalvik-cache/arm64/system@[email protected]
05-22 15:17:13.732 E/mono-rt (18283): 70f2f000-70f3f000 rw-p 00000000 fd:01 442559                             /data/dalvik-cache/arm64/system@[email protected]
05-22 15:17:13.732 E/mono-rt (18283): 70f3f000-70f44000 rw-p 00000000 fd:01 442560                             /data/dalvik-cache/arm64/system@[email protected]
05-22 15:17:13.732 E/mono-rt (18283): 70f44000-70f6f000 rw-p 00000000 fd:01 442561                             /data/dalvik-cache/arm64/system@[email protected]
05-22 15:17:13.732 E/mono-rt (18283): 70f6f000-71568000 rw-p 00000000 fd:01 442562                             /data/dalvik-cache/arm64/system@[email protected]
05-22 15:17:13.732 E/mono-rt (18283): 71568000-715ac000 rw-p 00000000 fd:01 442563                             /data/dalvik-cache/arm64/system@[email protected]
05-22 15:17:13.732 E/mono-rt (18283): 715ac000-715b7000 rw-p 00000000 fd:01 442564                             /data/dalvik-cache/arm64/system@[email protected]
05-22 15:17:13.732 E/mono-rt (18283): 715b7000-715c2000 rw-p 00000000 fd:01 442565                             /data/dalvik-cache/arm64/system@[email protected]
05-22 15:17:13.732 E/mono-rt (18283): 715c2000-715e8000 rw-p 00000000 fd:01 442566                             /data/dalvik-cache/arm64/system@[email protected]
05-22 15:17:13.732 E/mono-rt (18283): 715e8000-715ea000 rw-p 00000000 fd:01 442567                             /data/dalvik-cache/arm64/system@[email protected]
05-22 15:17:13.732 E/mono-rt (18283): 715ea000-715ed000 rw-p 00000000 fd:01 442568                             /data/dalvik-cache/arm64/system@[email protected]
05-22 15:17:13.732 E/mono-rt (18283): 715ed000-715ee000 rw-p 00000000 fd:01 442569                             /data/dalvik-cache/arm64/system@[email protected]
05-22 15:17:13.748 F/libc    (18283): Fatal signal 11 (SIGSEGV), code 1, fault addr 0x20 in tid 18283 (_Tablet.Android), pid 18283 (_Tablet.Android)

VS bug #897846

[bencat86]

This looks like it could be a regression of #2920?

[brendanzagaeski]

Thanks for the report! As a next step, if you get a chance, if you can repeat the app crash once more and collect the adb logcat -d output, that would be excellent:

1. Open Tools > Android > Android Adb Command Prompt.

2. Run the following command to clear the log on the device:

   adb logcat -c

3. Repeat the app crash once more.

4. Run the following command to collect the log from the device:

   adb logcat -d > "%USERPROFILE%\Desktop\adblogcat.txt"
   

5. Attach back the adblogcat.txt file from your desktop, or if you prefer, copy and paste just the section of it that starts with the "E/mono-rt" lines you included in the original description and ends after the section that starts with a "Build fingerprint:" line and includes a "backtrace:" section (the native backtrace).

The additional "backtrace:" information will often contain the name of the native function where the app exited unexpectedly, which can be helpful to distinguish among different native crashes.

(I have an initial suspicion that the scope of mono/mono#14170 might be larger than it initially appeared. That problem might be causing unexpected exits when debugging in more circumstances than just when continuing through an unhandled exception. The additional information from the "backtrace:" should hopefully provide an additional clue to confirm that idea or indicate that there is another separate problem involving native aborts.)

Thanks in advance!

[bencat86]

It didn't crash immediately this time, but didn't take long.
I also tried with an empty project, but unable to reproduce that way.
adblogcat.txt

[EP01]

Hi @brendanzagaeski, thanks for looking at this.

@darkblackcorner and I are actually working on the same project. I have done some additional testing on this issue and found that the issue only occurs on one of my devices (a Panasonic FZ-N1 MK2 - API Level 27). It happens regardless if the app is launched with the debugger or not. I have a feeling that this issue is specific to the arm64-v8a architecture, as that seems to be the common denominator between my log and @darkblackcorner. I have attached my log as well, mine still crashed immediately. I'll be interested to learn what you find.

Thanks again.

adblogcat_EP01.txt

[EP01]

Confirmed the issue is not present on the same device using the armeabi-v7a ABI.

[tipa]

I am having a very similar issue since the last VS19 update when using EntityFrameworkCore.Sqlite in my app. The app crashes with a similar (or same) error as above (SIGSEGV). More specifically, creating the database with Migrate() caused the crash and I was able to work around it by providing an empty database where EF7 expects it before the Migrate() call. However, this didn't solve the problem completely and the app is still crashing on some of my users devices.

I can also confirm that it doesn't crash with arm64-v8a disabled when debugging, but still crashes with armeabi-v7a at Release-mode.

If needed, I can provide a solution to reproduce the problem

[tipa]

Log & sample project:
adblogcat.txt
App1.zip

[brendanzagaeski]

Thanks much for the quick replies, log files, and test case! At first glance, it looks like the suspicion that this has the same root cause as mono/mono#14170 might be right. The mono_jit_info_get_method+8 native fault location from that issue is also appearing in the "backtrace" section of these new log files:

backtrace:
    #00 pc 0000000000177678  /data/app/Mono.Android.DebugRuntime-oFKYupVsEWJ0Dq7bXjLmiA==/lib/arm64/libmonosgen-64bit-2.0.so (mono_jit_info_get_method+8)
    #01 pc 00000000000be654  /data/app/Mono.Android.DebugRuntime-oFKYupVsEWJ0Dq7bXjLmiA==/lib/arm64/libmonosgen-64bit-2.0.so

I'll do one more quick confirmation with the test app tipa just provided to grab the backtrace with debug symbols added, and then I'll escalate the issue with the runtime and debugger engineers.

[brendanzagaeski]

Thanks again for the test case! The backtrace with symbols does indeed also match mono/mono#14170:

  * frame #0: 0x0000007126cf5da8 libart.so`art_sigsegv_fault
    frame #1: 0x0000007126cf62b4 libart.so`art::FaultManager::HandleFault(int, siginfo*, void*) + 356
    frame #2: 0x00000058b5382b5c app_process64`___lldb_unnamed_symbol20$$app_process64 + 572
    frame #3: 0x00000071acbdd870 [vdso]
    frame #4: 0x00000071107d1640 libmonosgen-2.0.d.so`mono_handle_exception_internal [inlined] jinfo_get_method(ji=0x0000000000000000) at mini-runtime.h:390
    frame #5: 0x00000071107d1638 libmonosgen-2.0.d.so`mono_handle_exception_internal(ctx=<unavailable>, obj=<unavailable>, resume=0, out_ji=<unavailable>) at mini-exceptions.c:2701
    frame #6: 0x00000071107d1640 libmonosgen-2.0.d.so`mono_handle_exception_internal [inlined] jinfo_get_method(ji=0x0000007108452a58) at mini-runtime.h:390
    frame #7: 0x00000071107d1638 libmonosgen-2.0.d.so`mono_handle_exception_internal(ctx=<unavailable>, obj=<unavailable>, resume=0, out_ji=<unavailable>) at mini-exceptions.c:2701
    frame #8: 0x00000071107d12b8 libmonosgen-2.0.d.so`mono_handle_exception(ctx=<unavailable>, obj=<unavailable>) at mini-exceptions.c:2988
    frame #9: 0x000000711080901c libmonosgen-2.0.d.so`mono_arm_throw_exception(arg=<unavailable>, pc=<unavailable>, int_regs=0x0000007fcd282870, fp_regs=0x0000007fcd282970, corlib=<unavailable>, rethrow=1) at exceptions-arm64.c:410

It looks like certain re-thrown exceptions are sufficient to cause this problem even if they are caught and handled within an external library. In this case, it looks like the exception that's triggering the native fault might be a Microsoft.Data.Sqlite.SqliteException that is thrown from Microsoft.Data.Sqlite.dll, and then re-thrown from Microsoft.EntityFrameworkCore.Relational.dll. If I set the debugger to break on all thrown exceptions, I can break on the original thrown exception and the re-thrown exception, but the app aborts after I then continue through the re-thrown exception.

I will escalate this with the runtime and debugger engineers.

---

For the runtime and debugger engineers, in case it might be helpful, here's a slightly adjusted test case to make the sqlite call happen on a button tap so that it's easier to attach the native debugger before the crash:

RethrownExceptionCrash.zip

[tipa]

Probably related, also this simple 2-liner crashes in a similar fashion:

try { throw new FileLoadException(); }
catch (System.Exception e) when (e is FileLoadException) { }

[thudugala]

xamarin/Xamarin.Forms#6269

[brendanzagaeski]

Additional notes for the runtime and debugger engineers:

I tested a number of the Xamarin.Android continuous development builds to attempt to narrow down the range of commits involved in this change in behavior. Long story short, the commit that introduced the problem was 06e920c, which updated the product build process to use Android NDK r19 to build the Mono runtime. It seems this changed the behavior of the Mono runtime in an unexpected way. I'm not sure if the problem is most likely due to an older bug in the Mono runtime that was only exposed after the change in the Android NDK or if the newer Android NDK version itself might have a bug.

Testing details

Good Behavior

Build tested: https://jenkins.xamarin.com/view/Xamarin.Android/job/xamarin-android-freestyle/1432/Azure/
Corresponding commit: 76fb90e

Behavior of the re-thrown exception test case from earlier in this issue

Runs without error.

(Note that once this app runs once successfully, it will not show the error again for another version of the Mono runtime unless the application data is cleared, presumably because the SQLite database does not need to be created again once it exists in the application data directory.)

Behavior of the filtered exception test case from the linked Xamarin.Forms issue

Continues running successfully after the TRY EXCEPTION button has been tapped.

Problematic Behavior

Build tested: https://jenkins.xamarin.com/view/Xamarin.Android/job/xamarin-android-freestyle/1436/
Corresponding commit: 06e920c

Behavior of the re-thrown exception test case from earlier in this issue

The application crashes:

* thread #1, name = 'ompanyname.App1', stop reason = breakpoint 1.1
  * frame #0: 0x0000007126cf5da8 libart.so`art_sigsegv_fault
    frame #1: 0x0000007126cf62b4 libart.so`art::FaultManager::HandleFault(int, siginfo*, void*) + 356
    frame #2: 0x00000058b5382b5c app_process64`___lldb_unnamed_symbol20$$app_process64 + 572
    frame #3: 0x00000071acbdd870 [vdso]
    frame #4: 0x00000071107c05e8 libmonosgen-2.0.d.so`mono_handle_exception_internal [inlined] jinfo_get_method(ji=0x0000000000000000) at mini-runtime.h:390
    frame #5: 0x00000071107c05e0 libmonosgen-2.0.d.so`mono_handle_exception_internal(ctx=<unavailable>, obj=<unavailable>, resume=0, out_ji=<unavailable>) at mini-exceptions.c:2630
    frame #6: 0x00000071107c05e8 libmonosgen-2.0.d.so`mono_handle_exception_internal [inlined] jinfo_get_method(ji=0x0000007109695998) at mini-runtime.h:390
    frame #7: 0x00000071107c05e0 libmonosgen-2.0.d.so`mono_handle_exception_internal(ctx=<unavailable>, obj=<unavailable>, resume=0, out_ji=<unavailable>) at mini-exceptions.c:2630
    frame #8: 0x00000071107c0260 libmonosgen-2.0.d.so`mono_handle_exception(ctx=<unavailable>, obj=<unavailable>) at mini-exceptions.c:2917
    frame #9: 0x00000071107f7ed0 libmonosgen-2.0.d.so`mono_arm_throw_exception(arg=<unavailable>, pc=<unavailable>, int_regs=0x0000007fcd2831f0, fp_regs=0x0000007fcd2832f0, corlib=<unavailable>, rethrow=1) at exceptions-arm64.c:410

Behavior of the filtered exception test case from the linked Xamarin.Forms issue

The application crashes:

* thread #1, name = 'com.companyname', stop reason = breakpoint 1.1
  * frame #0: 0x0000007126cf5da8 libart.so`art_sigsegv_fault
    frame #1: 0x0000007126cf62b4 libart.so`art::FaultManager::HandleFault(int, siginfo*, void*) + 356
    frame #2: 0x00000058b5382b5c app_process64`___lldb_unnamed_symbol20$$app_process64 + 572
    frame #3: 0x00000071acbdd870 [vdso]
    frame #4: 0x000000711014f5e8 libmonosgen-2.0.d.so`mono_handle_exception_internal [inlined] jinfo_get_method(ji=0x0000000000000000) at mini-runtime.h:390
    frame #5: 0x000000711014f5e0 libmonosgen-2.0.d.so`mono_handle_exception_internal(ctx=<unavailable>, obj=<unavailable>, resume=0, out_ji=<unavailable>) at mini-exceptions.c:2630
    frame #6: 0x000000711014f5e8 libmonosgen-2.0.d.so`mono_handle_exception_internal [inlined] jinfo_get_method(ji=0x000000710ab23aa0) at mini-runtime.h:390
    frame #7: 0x000000711014f5e0 libmonosgen-2.0.d.so`mono_handle_exception_internal(ctx=<unavailable>, obj=<unavailable>, resume=0, out_ji=<unavailable>) at mini-exceptions.c:2630
    frame #8: 0x000000711014f260 libmonosgen-2.0.d.so`mono_handle_exception(ctx=<unavailable>, obj=<unavailable>) at mini-exceptions.c:2917
    frame #9: 0x0000007110186ed0 libmonosgen-2.0.d.so`mono_arm_throw_exception(arg=<unavailable>, pc=<unavailable>, int_regs=0x0000007fcd2833b0, fp_regs=0x0000007fcd2834b0, corlib=<unavailable>, rethrow=0) at exceptions-arm64.c:410

---

(I'm omitting the results for the test case from mono/mono#14170 for the moment because those results were different in some curious ways across the versions I tested, and that scenario isn't as important as the more common scenarios from the other user-submitted test cases.)

[tobiasschulz]

Is there any workaround? Can I downgrade the VS2019 extension of xamarin android somehow?

[brendanzagaeski]

No general workaround that covers all the affected scenarios is known at this time.

It is possible to download the .vsix installer package for the previous version of the Xamarin.Android SDK from the list on https://github.com/xamarin/xamarin-android/, but the Visual Studio Installer aims to prevent potential invalid configurations, so it does not allow installing older versions of a .vsix than is currently installed. If you open the .vsix package as a ZIP archive, for example by renaming it to have a .zip extension and browsing it in Explorer, it is possible to view the $MSBuild directory and $ReferenceAssemblies directory that make up the Xamarin.Android SDK installation. In principle you can move the following subdirectories out of the way (adjusting the paths based on your Visual Studio install location):

• C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\Android
• C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\Xamarin.Android.Sdk.props
• C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\Xamarin.Android.Sdk.targets
• C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Novell
• C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\ReferenceAssemblies\Microsoft\Framework\MonoAndroid

And then you can copy the corresponding directories and files from within the .vsix archive. This is the technique that the setup-windows.exe command in the open source development build .zip archives use. Since this is approach is intended mostly for test usage of development builds, it would be recommended to use the full previous Visual Studio installation whenever possible instead. For example, in this case, the previous version of Visual Studio 2019 would be version 16.0. The installer for that previous version can be found via a Visual Studio subscription or the Dev Essentials program, for example using the Download button for Visual Studio 2017 on https://visualstudio.microsoft.com/vs/older-downloads/ and adjusting the search from Visual Studio 2017 to Visual Studio 2019.

[brendanzagaeski]

Reopening for now to use the closed status of this item to indicate when the fix is published.

[PiTi2k5]

Xamarin.Android WebClient app crash without an internet connection is fixed with Xamarin.Android.Sdk.9.3.0.23.vsix Thanks for fix

[ish-1313]

crash when clearing entry binded to numeric solved (xamarin/Xamarin.Forms#6336) . thanks

[herreruud]

I started experiencing this after the latest update, but in my case it was NOT resolved by installing the VSIX above. However, this only happens on release builds, and the problem dissapears when changing from D8/R8 to Proguard, but the (unmodified) code worked perfectly with R8/D8 before the update.

[brendanzagaeski]

@herreruud, thanks for the information! That sounds like it is probably a separate problem. If you get a chance, if you could file new issue with some details like the full text of the error message you are seeing, any zipped up example project or steps to reproduce you can share, and the adb logcat logs, that would be perfect. Thanks in advance!

[Drutol]

Can confirm that the provided vsix resolved the issue. Still not nice to wake up and see hundreds of crashes on Play Store...

[Minorsonek]

Had a sigsegv 11 error when doing Database.Migrate() using sqlite3 (EF etc.) and can confirm - this VSIX finally fixed the issue

Please proceed with making it into official xamarin

[acaliaro]

#3222 (comment)

[brendanzagaeski]

Windows fix published. The new Xamarin.Android SDK version 9.3.0.23 that includes the fix for this issue has now been published as part of Visual Studio 2019 version 16.1.4. Check for the latest updates or install the most recent release from https://visualstudio.microsoft.com/downloads/ to get the fix.

macOS fix published. The new Xamarin.Android SDK version 9.3.0.23 that includes the fix for this issue has now been released in the Stable updater channel in Visual Studio for Mac. Check for the latest updates or install the most recent release from https://visualstudio.microsoft.com/downloads/ to get the fix.

Thanks again for submitting this report that helped bring the fix to Visual Studio!

[acaliaro]

Installed, recompiled, debugged. Seems to work fine! Thanks @brendanzagaeski and others!

[NickeManarin]

Ok, I can confirm that updating VS to 16.1.4 fixed the issue for me. Thanks!

[ish-1313]

my case also fixed. thank you again

[SpiegelSoft]

This is not fixed for me. I'm using Visual Studio 16.1.4, with the latest NuGet packages.

=================================================================
Native Crash Reporting

Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.

=================================================================
Basic Fault Adddress Reporting

Memory around native instruction pointer (0xbe151068):0xbe151058 00 00 00 00 40 40 1f be 14 01 00 00 0c 00 00 00 ....@@..........
0xbe151068 88 e2 48 c8 0a 00 00 00 00 1d 1f ee 70 82 07 be ..H.........p...
0xbe151078 30 b2 14 be 00 00 00 00 00 01 00 00 00 00 00 00 0...............
0xbe151088 00 00 00 00 00 80 59 cc 0c 80 59 cc 18 80 59 cc ......Y...Y...Y.

No native Android stacktrace (see debuggerd output).

=========================================================06-30 14:17:27.711 E/mono-rt ( 4853): /proc/self/maps:

========
Managed Stacktrace:

  at <unknown> <0xffffffff>
  at clo@588-171:Invoke <0x00077>
  at Microsoft.FSharp.Control.AsyncPrimitives:CallThenInvokeNoHijackCheck <0x000d7>
  at Bind@495-1:Invoke <0x000b3>
  at Enceladus-Mobile-Common-IUserStore-GetUserFromCacheAsync@142-2:Invoke <0x00083>
  at Bind@495-1:Invoke <0x000b3>
  at clo@86-34:Invoke <0x00083>
  at Microsoft.FSharp.Control.AsyncPrimitives:CallThenInvoke <0x0029b>
  at Delay@1095:Invoke <0x0015f>
  at clo@85-36:Invoke <0x000eb>
  at Bind@495-1:Invoke <0x000b3>
  at Microsoft.FSharp.Control.Trampoline:Execute <0x0023f>
  at Microsoft.FSharp.Control.TrampolineHolder:ExecuteWithTrampoline <0x001cf>
  at Microsoft.FSharp.Control.AsyncPrimitives:continuation@973 <0x00107>
  at taskContinueWith@987:Invoke <0x000b3>
  at System.Threading.Tasks.ContinuationTaskFromResultTask`1:InnerInvoke <0x00143>
  at System.Threading.Tasks.Task:Execute <0x0007b>
  at System.Threading.Ta06-30 14:17:27.712 E/mono-rt ( 4853): 12c00000-12e00000 rw-p 00000000 00:05 30047                              /dev/ashmem/dalvik-main space (region space) (deleted)

sks.Task:ExecutionContextCallback <0x000af>
at System.Threading.ExecutionContext:RunInternal <0x0040b>
at System.Threading.ExecutionContext:Run <0x00073>
at System.Threading.Tasks.Task:ExecuteWithThreadLocal <0x00227>
at System.Threading.Tasks.Task:ExecuteEntry <0x001d7>
at System.Threading.Tasks.Task:System.Threading.IThreadPoolWorkItem.ExecuteWorkItem <0x0005f>
at System.Threading.ThreadPoolWorkQueue:Dispatch <0x00507>
at System.Threading._ThreadPoolWaitCallback:PerformWaitCallback <0x0007f>
at :runtime_invoke_bool <0x0007b>
=================================================================06-30 14:17:27.712 E/mono-rt ( 4853): 12e00000-12f80000 ---p 00200000 00:05 30047 /dev/ashmem/dalvik-main space (region space) (deleted)

06-30 14:17:27.712 E/mono-rt ( 4853): 12f80000-12fc0000 rw-p 00380000 00:05 30047 /dev/ashmem/dalvik-main space (region space) (deleted)
06-30 14:17:27.712 E/mono-rt ( 4853): 12fc0000-13040000 ---p 003c0000 00:05 30047 /dev/ashmem/dalvik-main space (region space) (deleted)
06-30 14:17:27.712 E/mono-rt ( 4853): 13040000-13080000 rw-p 00440000 00:05 30047 /dev/ashmem/dalvik-main space (region space) (deleted)
06-30 14:17:27.712 E/mono-rt ( 4853): 13080000-13140000 ---p 00480000 00:05 30047 /dev/ashmem/dalvik-main space (region space) (deleted)
06-30 14:17:27.712 E/mono-rt ( 4853): 13140000-2ac00000 rw-p 00540000 00:05 30047 /dev/ashmem/dalvik-main space (region space) (deleted)
06-30 14:17:27.712 E/mono-rt ( 4853): 6f44d000-6f468000 rw-p 00000000 103:24 1147231 /data/dalvik-cache/arm/system@[email protected]
06-30 14:17:27.712 E/mono-rt ( 4853): 6f468000-6f46b000 r--p 0001b000 103:24 1147231 /data/dalvik-cache/arm/system@[email protected]
06-30 14:17:27.712 E/mono-rt ( 4853): 6f46b000-6f46d000 rw-p 00000000 103:24 1147247 /data/dalvik-cache/arm/system@[email protected]
06-30 14:17:27.712 E/mono-rt ( 4853): 6f46d000-6f46e000 r--p 00002000 103:24 1147247 /data/dalvik-cache/arm/system@[email protected]
06-30 14:17:27.712 E/mono-rt ( 4853): 6f46e000-6f46f000 rw-p 00000000 103:24 1147250 /data/dalvik-cache/arm/system@[email protected]
06-30 14:17:27.712 E/mono-rt ( 4853): 6f46f000-6f470000 r--p 00001000 103:24 1147250 /data/dalvik-cache/arm/system@[email protected]
06-30 14:17:27.712 E/mono-rt ( 4853): 6f470000-6f471000 rw-p 00000000 103:24 1147253 /data/dalvik-cache/arm/system@[email protected]
06-30 14:17:27.712 E/mono-rt ( 4853): 6f471000-6f473000 rw-p 00000000 103:24 1147256 /data/dalvik-cache/arm/system@[email protected]
06-30 14:17:27.712 E/mono-rt ( 4853): 6f473000-6f474000 r--p 00002000 103:24 1147256 /data/dalvik-cache/arm/system@[email protected]
06-30 14:17:27.712 E/mono-rt ( 4853): 6f474000-6f689000 rw-p 00000000 103:24 1147259 /data/dalvik-cache/arm/system@[email protected]
06-30 14:17:27.712 E/mono-rt ( 4853): 6f689000-6f69d000 r--p 00215000 103:24 1147259 /data/dalvik-cache/arm/system@[email protected]
06-30 14:17:27.712 E/mono-rt ( 4853): 6f69d000-6f794000 rw-p 00000000 103:24 1147262 /data/dalvik-cache/arm/system@[email protected]
06-30 14:17:27.712 E/mono-rt ( 4853): 6f794000-6f7a6000 r--p 000f7000 103:24 1147262 /data/dalvik-cache/arm/system@[email protected]
06-30 14:17:27.712 E/mono-rt ( 4853): 6f7a6000-6f7d7000 rw-p 00000000 103:24 1147265 /data/dalvik-cache/arm/system@[email protected]
06-30 14:17:27.712 E/mono-rt ( 4853): 6f7d7000-6f7da000 r--p 00031000 103:24 1147265 /data/dalvik-cache/arm/system@[email protected]
06-30 14:17:27.712 E/mono-rt ( 4853): 6f7da000-6f807000 rw-p 00000000 103:24 1147268 /data/dalvik-cache/arm/system@[email protected]
06-30 14:17:27.712 E/mono-rt ( 4853): 6f807000-6f80a000 r--p 0002d000 103:24 1147268 /data/dalvik-cache/arm/system@[email protected]
06-30 14:17:27.712 E/mono-rt ( 4853): 6f80a000-6f860000 rw-p 00000000 103:24 1147271 /data/dalvik-cache/arm/system@[email protected]
06-30 14:17:27.714 F/libc ( 4853): Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0xbe151068 in tid 4962 (Thread Pool Wor), pid 4853

[brendanzagaeski]

@SpiegelSoft, thanks for the additional information! That crash would be something different from this issue (#3112) since the stack trace is from an arm ABI application rather than an arm64 ABI application. Based on the "code 2 (SEGV_ACCERR)" signal code you're seeing, I suspect you might be encountering the issue reported in #3198.

If you might have a project you can zip up and share on #3198 that demonstrates this problem, that would be excellent. See the latest comment there for a few possible options to share the project publicly or privately. Thanks in advance!

[jvillaro]

It´s happening again today after 16.7.1 update...

[brendanzagaeski]

@jvillaro, most likely you are seeing #4983. See #4983 (comment) for a way to workaround that issue. If that does not resolve the issue you are seeing, then please submit a new issue. Thanks in advance!

[jvillaro]

Hi! Yes, it worked perfectly. Thanks!

…

On Wed, Aug 12, 2020 at 12:08 PM Brendan Zagaeski ***@***.***> wrote: @jvillaro <https://github.com/jvillaro>, most likely you are seeing #4983 <#4983>. See #4983 (comment) <#4983 (comment)> for a way to workaround that issue. If that does not resolve the issue you are seeing, then please submit a new issue. Thanks in advance! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3112 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJUZCJX5EW4PNWXQUOAUTGTSAKV5ZANCNFSM4HOU6YCQ> .

-- Saludos, José A. Villaró M.

[shehrozeee]

@jvillaro, most likely you are seeing #4983. See #4983 (comment) for a way to workaround that issue. If that does not resolve the issue you are seeing, then please submit a new issue. Thanks in advance!

Spent a day one this .... But thank you. Finally able to hit my breakpoints.
Application was working just fine in release mode though.