-
Notifications
You must be signed in to change notification settings - Fork 528
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crash after startup after upgrade to VS 16.6.0 #4713
Comments
@rgroenewoudt would you be able to create a small sample app which reproduces the issue? I can't diagnose the cause from the information you provided, alas. Thanks! |
I'm still trying to create a sample app but I found out that I don't have any issues with |
@rgroenewoudt That's interesting... I will certainly need the sample to figure it out, though. Assembly preloading shouldn't have impact on the way typemaps work. What matters is whether it's a |
App3.zip |
During debugging I'm also getting messages for various classes from NuGet packages: |
@rgroenewoudt These messages are harmless - not all Java types are mapped. The real issue here is a segfault in Mono code, I'm investigating it now. |
So, the crash happens because of this line in the Mono runtime. Xamarin.Android runtime uses this code to load a managed type given its name - note that it passes
The fix is simple and I'll be opening a PR against Mono soon. It may take a few days to propagate to Xamarin.Android/master, I'll keep this issue updated. |
@rgroenewoudt PR for mono/master fixing this issue is up mono/mono#19839 |
Fixes: dotnet#4713 Context: mono/mono@10795da1c065c Context: mono/mono@8c085a99b32e9 Whenever Xamarin.Android runtime needs to instantiate a managed type, it first looks it up by calling the following function: MonoType *type = mono_reflection_type_from_name ("MyType, Assembly", nullptr); The `nullptr` pointer refers to an instance of the Mono `MonoImage` structure and if `null`, it should cause Mono to find the correct image containing the type and load it, if not already loaded. The pointer is propagated down the call chain inside Mono and due to one of the functions called not properly validating its arguments, the `null` pointer was dereferenced, leading to a crash similar to: libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4c0 in tid 11029 (ompanyname.app3), pid 11029 (ompanyname.app3) crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone /system/bin/tombstoned: received crash request for pid 11029 crash_dump64: performing dump of process 11029 (target tid = 11029) DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** DEBUG : Build fingerprint: 'google/sdk_gphone_x86_64/generic_x86_64:10/QSR1.190920.001/5891938:user/release-keys' DEBUG : Revision: '0' DEBUG : ABI: 'x86_64' DEBUG : Timestamp: 2020-05-25 14:45:29+0200 DEBUG : pid: 11029, tid: 11029, name: ompanyname.app3 >>> com.companyname.app3 <<< DEBUG : uid: 10134 DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4c0 DEBUG : Cause: null pointer dereference DEBUG : rax 000000000000002f rbx 0000000000000001 rcx 0000000000000000 rdx 0000000000000030 DEBUG : r8 0000000000000003 r9 000000000013e2e2 r10 0173eed800000000 r11 0000000000000206 DEBUG : r12 0000000000000000 r13 00007478530343c0 r14 00007478075eda33 r15 000074780763efb0 DEBUG : rdi 0000000000000000 rsi 00007478e2cb14d0 DEBUG : rbp 00007ffef3a35680 rsp 00007ffef3a355d0 rip 0000747807a4066a DEBUG : DEBUG : backtrace: DEBUG : #00 pc 00000000003ba66a /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonosgen-2.0.so (_mono_reflection_get_type_from_info+474) DEBUG : #1 pc 00000000003ba3d1 /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonosgen-2.0.so (mono_reflection_type_from_name_checked+321) DEBUG : #2 pc 00000000003ba26d /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonosgen-2.0.so (mono_reflection_type_from_name+125) DEBUG : #3 pc 000000000000ddb5 /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(char const*)+389) (BuildId: 9952f1cfe0d910ae631abc73479f88eef34fd71d) DEBUG : dotnet#4 pc 000000000000def3 /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(_MonoString*)+99) (BuildId: 9952f1cfe0d910ae631abc73479f88eef34fd71d) DEBUG : dotnet#5 pc 0000000000069532 <anonymous:5ad25000> Mono commit mono/mono@10795da1c06 fixes this issue. Other changes: * mono/mono@89d772a3abb Always include Unicode charinfo, so tar made in csc mode works in mcs mode (#19813) * mono/mono@e9d3af508e4 Bump bockbuild to get mono/bockbuild#159 * mono/mono@d6f0c25d34d [2020-02] Bump msbuild to track mono-2019-12 (#19661)
Fixes: dotnet#4713 Context: mono/mono@10795da1c065c Context: mono/mono@8c085a99b32e9 Whenever Xamarin.Android runtime needs to instantiate a managed type, it first looks it up by calling the following function: MonoType *type = mono_reflection_type_from_name ("MyType, Assembly", nullptr); The `nullptr` pointer refers to an instance of the Mono `MonoImage` structure and if `null`, it should cause Mono to find the correct image containing the type and load it, if not already loaded. The pointer is propagated down the call chain inside Mono and due to one of the functions called not properly validating its arguments, the `null` pointer was dereferenced, leading to a crash similar to: libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4c0 in tid 11029 (ompanyname.app3), pid 11029 (ompanyname.app3) crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone /system/bin/tombstoned: received crash request for pid 11029 crash_dump64: performing dump of process 11029 (target tid = 11029) DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** DEBUG : Build fingerprint: 'google/sdk_gphone_x86_64/generic_x86_64:10/QSR1.190920.001/5891938:user/release-keys' DEBUG : Revision: '0' DEBUG : ABI: 'x86_64' DEBUG : Timestamp: 2020-05-25 14:45:29+0200 DEBUG : pid: 11029, tid: 11029, name: ompanyname.app3 >>> com.companyname.app3 <<< DEBUG : uid: 10134 DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4c0 DEBUG : Cause: null pointer dereference DEBUG : rax 000000000000002f rbx 0000000000000001 rcx 0000000000000000 rdx 0000000000000030 DEBUG : r8 0000000000000003 r9 000000000013e2e2 r10 0173eed800000000 r11 0000000000000206 DEBUG : r12 0000000000000000 r13 00007478530343c0 r14 00007478075eda33 r15 000074780763efb0 DEBUG : rdi 0000000000000000 rsi 00007478e2cb14d0 DEBUG : rbp 00007ffef3a35680 rsp 00007ffef3a355d0 rip 0000747807a4066a DEBUG : DEBUG : backtrace: DEBUG : #00 pc 00000000003ba66a /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonosgen-2.0.so (_mono_reflection_get_type_from_info+474) DEBUG : #1 pc 00000000003ba3d1 /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonosgen-2.0.so (mono_reflection_type_from_name_checked+321) DEBUG : #2 pc 00000000003ba26d /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonosgen-2.0.so (mono_reflection_type_from_name+125) DEBUG : #3 pc 000000000000ddb5 /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(char const*)+389) (BuildId: 9952f1cfe0d910ae631abc73479f88eef34fd71d) DEBUG : dotnet#4 pc 000000000000def3 /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(_MonoString*)+99) (BuildId: 9952f1cfe0d910ae631abc73479f88eef34fd71d) DEBUG : dotnet#5 pc 0000000000069532 <anonymous:5ad25000> Mono commit mono/mono@10795da1c06 fixes this issue. Other changes: * mono/mono@89d772a3abb Always include Unicode charinfo, so tar made in csc mode works in mcs mode (#19813) * mono/mono@e9d3af508e4 Bump bockbuild to get mono/bockbuild#159 * mono/mono@d6f0c25d34d [2020-02] Bump msbuild to track mono-2019-12 (#19661)
Fixes: #4713 Context: mono/mono@10795da1c065c Context: mono/mono@8c085a99b32e9 Changes: mono/mono@075c3f0...8c085a9 * mono/mono@8c085a99b32: [reflection] Check whether a pointer is valid before dereferencing (#19842) * mono/mono@89d772a3abb: Always include Unicode charinfo, so tar made in csc mode works in mcs mode (#19813) * mono/mono@e9d3af508e4: Bump bockbuild to get mono/bockbuild#159 * mono/mono@d6f0c25d34d: [2020-02] Bump msbuild to track mono-2019-12 (#19661) Whenever Xamarin.Android runtime needs to instantiate a managed type, it first looks it up by calling: MonoType *type = mono_reflection_type_from_name ("MyType, Assembly", nullptr); The `nullptr` pointer refers to an instance of the Mono `MonoImage` structure and if `nullptr`, it should cause Mono to find the correct image containing the type and load it, if not already loaded. The pointer is propagated down the call chain inside Mono and due to one of the functions called not properly validating its arguments, the `nullptr` pointer was dereferenced, leading to a crash similar to: libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4c0 in tid 11029 (ompanyname.app3), pid 11029 (ompanyname.app3) crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone /system/bin/tombstoned: received crash request for pid 11029 crash_dump64: performing dump of process 11029 (target tid = 11029) DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** DEBUG : Build fingerprint: 'google/sdk_gphone_x86_64/generic_x86_64:10/QSR1.190920.001/5891938:user/release-keys' DEBUG : Revision: '0' DEBUG : ABI: 'x86_64' DEBUG : Timestamp: 2020-05-25 14:45:29+0200 DEBUG : pid: 11029, tid: 11029, name: ompanyname.app3 >>> com.companyname.app3 <<< DEBUG : uid: 10134 DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4c0 DEBUG : Cause: null pointer dereference DEBUG : rax 000000000000002f rbx 0000000000000001 rcx 0000000000000000 rdx 0000000000000030 DEBUG : r8 0000000000000003 r9 000000000013e2e2 r10 0173eed800000000 r11 0000000000000206 DEBUG : r12 0000000000000000 r13 00007478530343c0 r14 00007478075eda33 r15 000074780763efb0 DEBUG : rdi 0000000000000000 rsi 00007478e2cb14d0 DEBUG : rbp 00007ffef3a35680 rsp 00007ffef3a355d0 rip 0000747807a4066a DEBUG : DEBUG : backtrace: DEBUG : #00 pc 00000000003ba66a /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonosgen-2.0.so (_mono_reflection_get_type_from_info+474) DEBUG : #1 pc 00000000003ba3d1 /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonosgen-2.0.so (mono_reflection_type_from_name_checked+321) DEBUG : #2 pc 00000000003ba26d /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonosgen-2.0.so (mono_reflection_type_from_name+125) DEBUG : #3 pc 000000000000ddb5 /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(char const*)+389) (BuildId: 9952f1cfe0d910ae631abc73479f88eef34fd71d) DEBUG : #4 pc 000000000000def3 /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(_MonoString*)+99) (BuildId: 9952f1cfe0d910ae631abc73479f88eef34fd71d) DEBUG : #5 pc 0000000000069532 <anonymous:5ad25000> Mono commit mono/mono@10795da1c06 fixes this issue.
Fixes: #4713 Context: mono/mono@10795da1c065c Context: mono/mono@8c085a99b32e9 Changes: mono/mono@075c3f0...8c085a9 * mono/mono@8c085a99b32: [reflection] Check whether a pointer is valid before dereferencing (#19842) * mono/mono@89d772a3abb: Always include Unicode charinfo, so tar made in csc mode works in mcs mode (#19813) * mono/mono@e9d3af508e4: Bump bockbuild to get mono/bockbuild#159 * mono/mono@d6f0c25d34d: [2020-02] Bump msbuild to track mono-2019-12 (#19661) Whenever Xamarin.Android runtime needs to instantiate a managed type, it first looks it up by calling: MonoType *type = mono_reflection_type_from_name ("MyType, Assembly", nullptr); The `nullptr` pointer refers to an instance of the Mono `MonoImage` structure and if `nullptr`, it should cause Mono to find the correct image containing the type and load it, if not already loaded. The pointer is propagated down the call chain inside Mono and due to one of the functions called not properly validating its arguments, the `nullptr` pointer was dereferenced, leading to a crash similar to: libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4c0 in tid 11029 (ompanyname.app3), pid 11029 (ompanyname.app3) crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone /system/bin/tombstoned: received crash request for pid 11029 crash_dump64: performing dump of process 11029 (target tid = 11029) DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** DEBUG : Build fingerprint: 'google/sdk_gphone_x86_64/generic_x86_64:10/QSR1.190920.001/5891938:user/release-keys' DEBUG : Revision: '0' DEBUG : ABI: 'x86_64' DEBUG : Timestamp: 2020-05-25 14:45:29+0200 DEBUG : pid: 11029, tid: 11029, name: ompanyname.app3 >>> com.companyname.app3 <<< DEBUG : uid: 10134 DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4c0 DEBUG : Cause: null pointer dereference DEBUG : rax 000000000000002f rbx 0000000000000001 rcx 0000000000000000 rdx 0000000000000030 DEBUG : r8 0000000000000003 r9 000000000013e2e2 r10 0173eed800000000 r11 0000000000000206 DEBUG : r12 0000000000000000 r13 00007478530343c0 r14 00007478075eda33 r15 000074780763efb0 DEBUG : rdi 0000000000000000 rsi 00007478e2cb14d0 DEBUG : rbp 00007ffef3a35680 rsp 00007ffef3a355d0 rip 0000747807a4066a DEBUG : DEBUG : backtrace: DEBUG : #00 pc 00000000003ba66a /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonosgen-2.0.so (_mono_reflection_get_type_from_info+474) DEBUG : #1 pc 00000000003ba3d1 /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonosgen-2.0.so (mono_reflection_type_from_name_checked+321) DEBUG : #2 pc 00000000003ba26d /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonosgen-2.0.so (mono_reflection_type_from_name+125) DEBUG : #3 pc 000000000000ddb5 /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(char const*)+389) (BuildId: 9952f1cfe0d910ae631abc73479f88eef34fd71d) DEBUG : #4 pc 000000000000def3 /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(_MonoString*)+99) (BuildId: 9952f1cfe0d910ae631abc73479f88eef34fd71d) DEBUG : #5 pc 0000000000069532 <anonymous:5ad25000> Mono commit mono/mono@10795da1c06 fixes this issue.
Update Xamarin.AndroidX.Lifecycle to 2.2.0.1 but STILL CRASH with AndroidEnablePreloadAssemblies = False. There are some update?? |
@giuseppenovielli, thanks for the question. A fix for the issue has been merged to the development branch but is not yet published within Visual Studio 2019. If everything goes as planned, this fix will be included in the next versions of Visual Studio 2019 version 16.7 Preview and Visual Studio 2019 for Mac version 8.7 Preview. I will be adding an "In Preview: " milestone to this issue along with a comment as soon as the fix is published in a Preview version. Here's an example of how the comment will look: #4409 (comment). |
Thanks again for submitting this issue! Release status update A new Preview version of Xamarin.Android has now been published that includes the fix for this item. The fix is not yet included in a Release version. I will update this again when a Release version is available that includes the fix. Fix included in Xamarin.Android 10.4.0.0. Fix included on Windows in Visual Studio 2019 version 16.7 Preview 3. To try the Preview version that includes the fix, check for the latest updates in Visual Studio Preview. Fix included on macOS in Visual Studio 2019 for Mac version 8.7 Preview 3. To try the Preview version that includes the fix, check for the latest updates on the Preview updater channel. |
Release status update A new Release version of Xamarin.Android has now been published that includes the fix for this item. Fix included in Xamarin.Android SDK version 11.0.0.3. Fix included on Windows in Visual Studio 2019 version 16.7. To get the new version that includes the fix, check for the latest updates or install the most recent release from https://visualstudio.microsoft.com/downloads/. Fix included on macOS in Visual Studio 2019 for Mac version 8.7. To get the new version that includes the fix, check for the latest updates on the Stable updater channel. |
Hi @brendanzagaeski crash still happens after update of VS Mac on debug mode. Release mode working fine. Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x5f656b6f766e59 My VS Mac details down below. === Visual Studio Community 2019 for Mac === Version 8.7 (build 2037)
=== Mono Framework MDK === Runtime: === Roslyn (Language Service) === 3.7.0-6.20371.12+917b9dfae12e3b6cb266a3c062fb20a1e9d5fb06 === NuGet === Version: 5.7.0.6702 === .NET Core SDK === SDK: /usr/local/share/dotnet/sdk/3.1.302/Sdks === .NET Core Runtime === Runtime: /usr/local/share/dotnet/dotnet === Xamarin.Profiler === Version: 1.6.12.29 === Updater === Version: 11 === Apple Developer Tools === Xcode 11.6 (16141) === Xamarin.Mac === Version: 6.20.2.2 (Visual Studio Community) === Xamarin.iOS === Version: 13.20.2.2 (Visual Studio Community) === Xamarin Designer === Version: 16.7.0.492 === Xamarin.Android === Version: 11.0.0.3 (Visual Studio Community) SDK Tools Version: 26.1.1 Build Information: === Microsoft OpenJDK for Mobile === Java SDK: /Users/keremozcan/Library/Developer/Xamarin/jdk/microsoft_dist_openjdk_1.8.0.25 === Android SDK Manager === Version: 16.7.0.13 === Android Device Manager === Version: 16.7.0.18 === Build Information === Release ID: 807002037 === Operating System === Mac OS X 10.15.5 |
@grendello that's the problem we have facing. Thanks. It worked! |
Crash immediately after starting after upgrading Visual Studio 2019 to 16.6.0:
Version Information
VS2019 16.6.
No issues with 16.5
Project
References in my project:
The text was updated successfully, but these errors were encountered: