App crashes with debugger attached #2920
Assignees
Labels
Area: Mono Runtime
Mono-related issues: BCL bugs, AOT issues, etc.
bug
Component does not function as intended.
regression
Milestone
Comments
JonDouglas
added
Area: Mono Runtime
|
Detailed repro steps here with full source: dotMorten/MauiEx#41 (comment) |
|
@lambdageek please handle this issue |
|
I can also reproduce this issue, on Win10 with VS2019. Reproduced devices : Getac ZX70 (intel processor, 64bit) Android 5.1 |
|
Seeing this issue, too in a Xamarin.Forms application: Please let me know if I can provide further details to assist with the debugging. |
|
@lambdageek here is how I was able to reproduce (hit me up on Slack if you need more info):
You might have to do the cycle one time or more. Once the app crashes, you can just launch the app by tapping the app icon. The crash seems to go away when no debugger is attached at all--no changes in app settings required. |
|
@jonathanpeppers I never had to go beyond step 3 (always crashes 2-3 seconds after the page has loaded) |
|
Ok yes, maybe you can just wait a few seconds on that second page -- I may have been tapping buttons in a state of panic. |
|
I found that issue occurs after some relatively constant amount of time no matter what I do in the app. The crash occurs also when using Rider. |
|
Hi, I encountered the same issue. With a Xamarin android native app and Visual Studio 2019 for Mac. |
|
I encounter this issue when i downgrade the xamarin.android to 9.1.8 and/or remove my d8/r8 settings in the .csproj. This all happened after updating to Visual Studios 2019. iOS works fine, but Android is not working for me. |
|
I have the same problem here. However, when I created a new Xamarin.Forms application in VS2019, the debugger stays attached. Very strange why my existing application constantly de-attachted by the debugger. |
|
I'm using an Seeing this sort of thing when the crash is happening using the repro from #2920 (comment)
Update: my guess here was wrong. See #2920 (comment) for a clean stack trace of what's going wrong. It's the debugger agent trying to process a thread_stopped profiler event from a thread that is already detached. |
|
Serious bugs like these should be given topmost priority, not stay unfixed for 4 days without any indication of when to expect a fix 🙄 |
|
I'm also facing this problem after updating to recent Visual Studio for Mac 2019. Our Xamarin.Android app compiles and runs but slightly crashes after passing our custom splash screen. This only started happening after updating to the recent release. Exact Xamarin version used is detailed below as well as Application Output showing the crash details. —————————————————————————————————————————— |
|
This is a pretty big blocker for our enterprise Android app that can not be debugged! Surely this was tested before making VS 2019 GA? Hope it gets fixed ASAP! |
Notes for the soft debugger and runtime engineers about using `sdb` and `lldb` at the same time with the test case
Additional results with these stepsWhen the segmentation fault occurs, The backtrace of thread 19 is: The backtrace of thread 1 is: |
|
Additional results The backtrace in my previous comment was from an Android 7.1 (API level 25) x86 emulator. On a Google Pixel 3 Android 9.0 (API level 28) device, the backtrace I get is: |
lambdageek
added a commit
to lambdageek/mono
that referenced
this issue
Apr 8, 2019
The thread_stopped profiler event can be raised by the thread_info_key_dtor tls key destructor when the thread is already doesn't have a domain set. In that case, don't call process_profiler_event since it cannot handle a thread with null TLS values. Addresses dotnet/android#2920 with the following stack trace ``` * thread #20, name = 'Filter', stop reason = signal SIGSEGV: invalid address (fault address: 0xbc) * frame #0: libmonosgen-2.0.so`mono_class_vtable_checked(domain=0x0000000000000000, klass=0x0000007200230648, error=0x00000071e92f9178) at object.c:1890 frame #1: libmonosgen-2.0.so`get_current_thread_ptr_for_domain(domain=0x0000000000000000, thread=0x00000071ebfec508) at threads.c:595 frame #2: libmonosgen-2.0.so`mono_thread_current at threads.c:1939 frame #3: libmonosgen-2.0.so`process_event(event=<unavailable>, arg=<unavailable>, il_offset=<unavailable>, ctx=<unavailable>, events=<unavailable>, suspend_policy=<unavailable>) at debugger-agent.c:3715 frame #4: libmonosgen-2.0.so`thread_end [inlined] process_profiler_event(event=EVENT_KIND_THREAD_DEATH, arg=0x00000071ebfec508) at debugger-agent.c:3875 frame #5: libmonosgen-2.0.so`thread_end(prof=<unavailable>, tid=<unavailable>) at debugger-agent.c:3991 frame #6: libmonosgen-2.0.so`mono_profiler_raise_thread_stopped(tid=<unavailable>) at profiler-events.h:105 frame #7: libmonosgen-2.0.so`mono_thread_detach_internal(thread=<unavailable>) at threads.c:979 frame #8: libmonosgen-2.0.so`thread_detach(info=0x00000071e949a000) at threads.c:3215 frame #9: libmonosgen-2.0.so`unregister_thread(arg=<unavailable>) at mono-threads.c:544 frame #10: libmonosgen-2.0.so`thread_info_key_dtor(arg=0x00000071e949a000) at mono-threads.c:774 frame #11: 0x00000072899c58e8 libc.so`pthread_key_clean_all() + 124 frame #12: 0x00000072899c5374 libc.so`pthread_exit + 76 frame #13: 0x00000072899c5264 libc.so`__pthread_start(void*) + 44 frame #14: 0x000000728996617c libc.so`__start_thread + 72 ```
|
@brendanzagaeski reinstalled Visual Studio and the issue is fixed! Thanks |
|
so i'm guessing this issue means that no one gets to use xamarin test cloud for testing xamarin builds at microsoft? there's one free device guys /s |
I first reported this back in January, a couple of days after preview 2 was released. Someone started looking at it quite quickly but seemed to struggle with repro steps. Sadly I didn't have time back then to try and create a small test application as we were at a critical point in our mobile app development. |
|
Windows fix published. The new Xamarin.Android SDK version 9.2.3.0 that includes the fix for this issue has now been published as part of Visual Studio 2019 version 16.0.3. Check for the latest updates or install the most recent release from https://visualstudio.microsoft.com/downloads/ to get the fix. |
akoeplinger
pushed a commit
to mono/mono
that referenced
this issue
May 7, 2019
The thread_stopped profiler event can be raised by the thread_info_key_dtor tls key destructor when the thread is already doesn't have a domain set. In that case, don't call process_profiler_event since it cannot handle a thread with null TLS values. Addresses dotnet/android#2920 with the following stack trace ``` * thread #20, name = 'Filter', stop reason = signal SIGSEGV: invalid address (fault address: 0xbc) * frame #0: libmonosgen-2.0.so`mono_class_vtable_checked(domain=0x0000000000000000, klass=0x0000007200230648, error=0x00000071e92f9178) at object.c:1890 frame #1: libmonosgen-2.0.so`get_current_thread_ptr_for_domain(domain=0x0000000000000000, thread=0x00000071ebfec508) at threads.c:595 frame #2: libmonosgen-2.0.so`mono_thread_current at threads.c:1939 frame #3: libmonosgen-2.0.so`process_event(event=<unavailable>, arg=<unavailable>, il_offset=<unavailable>, ctx=<unavailable>, events=<unavailable>, suspend_policy=<unavailable>) at debugger-agent.c:3715 frame #4: libmonosgen-2.0.so`thread_end [inlined] process_profiler_event(event=EVENT_KIND_THREAD_DEATH, arg=0x00000071ebfec508) at debugger-agent.c:3875 frame #5: libmonosgen-2.0.so`thread_end(prof=<unavailable>, tid=<unavailable>) at debugger-agent.c:3991 frame #6: libmonosgen-2.0.so`mono_profiler_raise_thread_stopped(tid=<unavailable>) at profiler-events.h:105 frame #7: libmonosgen-2.0.so`mono_thread_detach_internal(thread=<unavailable>) at threads.c:979 frame #8: libmonosgen-2.0.so`thread_detach(info=0x00000071e949a000) at threads.c:3215 frame #9: libmonosgen-2.0.so`unregister_thread(arg=<unavailable>) at mono-threads.c:544 frame #10: libmonosgen-2.0.so`thread_info_key_dtor(arg=0x00000071e949a000) at mono-threads.c:774 frame #11: 0x00000072899c58e8 libc.so`pthread_key_clean_all() + 124 frame #12: 0x00000072899c5374 libc.so`pthread_exit + 76 frame #13: 0x00000072899c5264 libc.so`__pthread_start(void*) + 44 frame #14: 0x000000728996617c libc.so`__start_thread + 72 ```
|
@brendanzagaeski It looks like this problem (or a very similar one) has re-occurred with VS 16.1.0 (Xamarin.Android 9.3.0.22). Was this fix merged up to 9.3? |
|
@EP01 , yes the fix for this particular issue is present in the Xamarin.Android 9.3.0.22 as shipped in Visual Studio 2019 version 16.1. (I also did a quick double-check of one of the test cases with that version just now to make sure it still debugged successfully, and it worked correctly.) That said, I have an initial suspicion that the scope of mono/mono#14170 (listed as a known issue in the Xamarin.Android 9.3 release notes) 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. Another user has reported a similar behavior in #3112, so I'll recommend to continue the conversation there to help figure out what is happening in this new scenario. Thanks! |
|
same issue for visual studio 16.1.1 and 16.2.0 preview 1 versions. |
|
@brendanzagaeski how can i download visual studio 16.0.3 community version? |
|
Does Xamarin even test serious bugs like these? |
|
I can confirm that I am getting the same problem for Visual Studio Version 16.1.1. |
I believe the previous version downloads are only available for Professional and higher editions. That said, there is a possible approach to downgrade just the Xamarin.Android SDK by some manual file copying in the Community edition. See #3112 (comment) for additional details. For other users seeing a similar behavior as this issue (#2920) in Visual Studio 2019 version 16.1 or higher, I'll recommend to switch over to following #3112 for further updates. It turns out the crash in Visual Studio 2019 version 16.1 has a different cause and can happen with or without the debugger attached. |
|
I might have some additional info, recently due to Android requiring to go to 64bits as in a few months I ran into a similiar problem. When the App Architecture is changed from "armeabi-v7a" to "arm64-v8a" it throws me a very simliliar errors. When logging in using Microsoft.Azure.Mobile.Client through a async UI thread it will work. It will only crash when the request hits a timeout. Additional info:
Code: Stack traces: |
|
People, is this bug ever going to be fixed? |
|
The best place to follow for additional information about the problem in Visual Studio 2019 version 16.1 and higher is: #3112 (or the corresponding item on Developer Community). For example, I'll make sure those issues are switched to the closed state when a version of Visual Studio 2019 version 16.1 with a fix for the issue is released, so you'll be able to watch for the state change to get a notification. There is a candidate change in progress to resolve the issue. (For additional background context, the crash in Visual Studio 2019 version 16.1 has a new unrelated cause, and can happen with or without the debugger attached.) |
|
Guys, the problem is resolved for debugging (in 16.1.2 and 16.1.3) on the main thread, but I am reproducing it randomly when debugging background threads. Reproduced with: |
monojenkins
pushed a commit
to monojenkins/mono
that referenced
this issue
Jun 14, 2019
The thread_stopped profiler event can be raised by the thread_info_key_dtor tls key destructor when the thread is already doesn't have a domain set. In that case, don't call process_profiler_event since it cannot handle a thread with null TLS values. Addresses dotnet/android#2920 with the following stack trace ``` * thread mono#20, name = 'Filter', stop reason = signal SIGSEGV: invalid address (fault address: 0xbc) * frame #0: libmonosgen-2.0.so`mono_class_vtable_checked(domain=0x0000000000000000, klass=0x0000007200230648, error=0x00000071e92f9178) at object.c:1890 frame mono#1: libmonosgen-2.0.so`get_current_thread_ptr_for_domain(domain=0x0000000000000000, thread=0x00000071ebfec508) at threads.c:595 frame mono#2: libmonosgen-2.0.so`mono_thread_current at threads.c:1939 frame mono#3: libmonosgen-2.0.so`process_event(event=<unavailable>, arg=<unavailable>, il_offset=<unavailable>, ctx=<unavailable>, events=<unavailable>, suspend_policy=<unavailable>) at debugger-agent.c:3715 frame mono#4: libmonosgen-2.0.so`thread_end [inlined] process_profiler_event(event=EVENT_KIND_THREAD_DEATH, arg=0x00000071ebfec508) at debugger-agent.c:3875 frame mono#5: libmonosgen-2.0.so`thread_end(prof=<unavailable>, tid=<unavailable>) at debugger-agent.c:3991 frame mono#6: libmonosgen-2.0.so`mono_profiler_raise_thread_stopped(tid=<unavailable>) at profiler-events.h:105 frame mono#7: libmonosgen-2.0.so`mono_thread_detach_internal(thread=<unavailable>) at threads.c:979 frame mono#8: libmonosgen-2.0.so`thread_detach(info=0x00000071e949a000) at threads.c:3215 frame mono#9: libmonosgen-2.0.so`unregister_thread(arg=<unavailable>) at mono-threads.c:544 frame mono#10: libmonosgen-2.0.so`thread_info_key_dtor(arg=0x00000071e949a000) at mono-threads.c:774 frame mono#11: 0x00000072899c58e8 libc.so`pthread_key_clean_all() + 124 frame mono#12: 0x00000072899c5374 libc.so`pthread_exit + 76 frame mono#13: 0x00000072899c5264 libc.so`__pthread_start(void*) + 44 frame mono#14: 0x000000728996617c libc.so`__start_thread + 72 ```
monojenkins
pushed a commit
to monojenkins/mono
that referenced
this issue
Jun 14, 2019
The thread_stopped profiler event can be raised by the thread_info_key_dtor tls key destructor when the thread is already doesn't have a domain set. In that case, don't call process_profiler_event since it cannot handle a thread with null TLS values. Addresses dotnet/android#2920 with the following stack trace ``` * thread mono#20, name = 'Filter', stop reason = signal SIGSEGV: invalid address (fault address: 0xbc) * frame #0: libmonosgen-2.0.so`mono_class_vtable_checked(domain=0x0000000000000000, klass=0x0000007200230648, error=0x00000071e92f9178) at object.c:1890 frame mono#1: libmonosgen-2.0.so`get_current_thread_ptr_for_domain(domain=0x0000000000000000, thread=0x00000071ebfec508) at threads.c:595 frame mono#2: libmonosgen-2.0.so`mono_thread_current at threads.c:1939 frame mono#3: libmonosgen-2.0.so`process_event(event=<unavailable>, arg=<unavailable>, il_offset=<unavailable>, ctx=<unavailable>, events=<unavailable>, suspend_policy=<unavailable>) at debugger-agent.c:3715 frame mono#4: libmonosgen-2.0.so`thread_end [inlined] process_profiler_event(event=EVENT_KIND_THREAD_DEATH, arg=0x00000071ebfec508) at debugger-agent.c:3875 frame mono#5: libmonosgen-2.0.so`thread_end(prof=<unavailable>, tid=<unavailable>) at debugger-agent.c:3991 frame mono#6: libmonosgen-2.0.so`mono_profiler_raise_thread_stopped(tid=<unavailable>) at profiler-events.h:105 frame mono#7: libmonosgen-2.0.so`mono_thread_detach_internal(thread=<unavailable>) at threads.c:979 frame mono#8: libmonosgen-2.0.so`thread_detach(info=0x00000071e949a000) at threads.c:3215 frame mono#9: libmonosgen-2.0.so`unregister_thread(arg=<unavailable>) at mono-threads.c:544 frame mono#10: libmonosgen-2.0.so`thread_info_key_dtor(arg=0x00000071e949a000) at mono-threads.c:774 frame mono#11: 0x00000072899c58e8 libc.so`pthread_key_clean_all() + 124 frame mono#12: 0x00000072899c5374 libc.so`pthread_exit + 76 frame mono#13: 0x00000072899c5264 libc.so`__pthread_start(void*) + 44 frame mono#14: 0x000000728996617c libc.so`__start_thread + 72 ```
This was referenced Jun 14, 2019
marek-safar
pushed a commit
to mono/mono
that referenced
this issue
Jun 15, 2019
The thread_stopped profiler event can be raised by the thread_info_key_dtor tls key destructor when the thread is already doesn't have a domain set. In that case, don't call process_profiler_event since it cannot handle a thread with null TLS values. Addresses dotnet/android#2920 with the following stack trace ``` * thread #20, name = 'Filter', stop reason = signal SIGSEGV: invalid address (fault address: 0xbc) * frame #0: libmonosgen-2.0.so`mono_class_vtable_checked(domain=0x0000000000000000, klass=0x0000007200230648, error=0x00000071e92f9178) at object.c:1890 frame #1: libmonosgen-2.0.so`get_current_thread_ptr_for_domain(domain=0x0000000000000000, thread=0x00000071ebfec508) at threads.c:595 frame #2: libmonosgen-2.0.so`mono_thread_current at threads.c:1939 frame #3: libmonosgen-2.0.so`process_event(event=<unavailable>, arg=<unavailable>, il_offset=<unavailable>, ctx=<unavailable>, events=<unavailable>, suspend_policy=<unavailable>) at debugger-agent.c:3715 frame #4: libmonosgen-2.0.so`thread_end [inlined] process_profiler_event(event=EVENT_KIND_THREAD_DEATH, arg=0x00000071ebfec508) at debugger-agent.c:3875 frame #5: libmonosgen-2.0.so`thread_end(prof=<unavailable>, tid=<unavailable>) at debugger-agent.c:3991 frame #6: libmonosgen-2.0.so`mono_profiler_raise_thread_stopped(tid=<unavailable>) at profiler-events.h:105 frame #7: libmonosgen-2.0.so`mono_thread_detach_internal(thread=<unavailable>) at threads.c:979 frame #8: libmonosgen-2.0.so`thread_detach(info=0x00000071e949a000) at threads.c:3215 frame #9: libmonosgen-2.0.so`unregister_thread(arg=<unavailable>) at mono-threads.c:544 frame #10: libmonosgen-2.0.so`thread_info_key_dtor(arg=0x00000071e949a000) at mono-threads.c:774 frame #11: 0x00000072899c58e8 libc.so`pthread_key_clean_all() + 124 frame #12: 0x00000072899c5374 libc.so`pthread_exit + 76 frame #13: 0x00000072899c5264 libc.so`__pthread_start(void*) + 44 frame #14: 0x000000728996617c libc.so`__start_thread + 72 ```
marek-safar
pushed a commit
to mono/mono
that referenced
this issue
Jun 15, 2019
The thread_stopped profiler event can be raised by the thread_info_key_dtor tls key destructor when the thread is already doesn't have a domain set. In that case, don't call process_profiler_event since it cannot handle a thread with null TLS values. Addresses dotnet/android#2920 with the following stack trace ``` * thread #20, name = 'Filter', stop reason = signal SIGSEGV: invalid address (fault address: 0xbc) * frame #0: libmonosgen-2.0.so`mono_class_vtable_checked(domain=0x0000000000000000, klass=0x0000007200230648, error=0x00000071e92f9178) at object.c:1890 frame #1: libmonosgen-2.0.so`get_current_thread_ptr_for_domain(domain=0x0000000000000000, thread=0x00000071ebfec508) at threads.c:595 frame #2: libmonosgen-2.0.so`mono_thread_current at threads.c:1939 frame #3: libmonosgen-2.0.so`process_event(event=<unavailable>, arg=<unavailable>, il_offset=<unavailable>, ctx=<unavailable>, events=<unavailable>, suspend_policy=<unavailable>) at debugger-agent.c:3715 frame #4: libmonosgen-2.0.so`thread_end [inlined] process_profiler_event(event=EVENT_KIND_THREAD_DEATH, arg=0x00000071ebfec508) at debugger-agent.c:3875 frame #5: libmonosgen-2.0.so`thread_end(prof=<unavailable>, tid=<unavailable>) at debugger-agent.c:3991 frame #6: libmonosgen-2.0.so`mono_profiler_raise_thread_stopped(tid=<unavailable>) at profiler-events.h:105 frame #7: libmonosgen-2.0.so`mono_thread_detach_internal(thread=<unavailable>) at threads.c:979 frame #8: libmonosgen-2.0.so`thread_detach(info=0x00000071e949a000) at threads.c:3215 frame #9: libmonosgen-2.0.so`unregister_thread(arg=<unavailable>) at mono-threads.c:544 frame #10: libmonosgen-2.0.so`thread_info_key_dtor(arg=0x00000071e949a000) at mono-threads.c:774 frame #11: 0x00000072899c58e8 libc.so`pthread_key_clean_all() + 124 frame #12: 0x00000072899c5374 libc.so`pthread_exit + 76 frame #13: 0x00000072899c5264 libc.so`__pthread_start(void*) + 44 frame #14: 0x000000728996617c libc.so`__start_thread + 72 ```
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
and others
Steps to Reproduce
Expected Behavior
App runs without random crashes
Actual Behavior
When the App crashes it outputs a crash report, without having any useful stack trace to the App being at fault.
When trying to debug with VS for Mac I only get:
Version Information
Latest version of VS for Mac stable or VS2019 GA (was also an issue on VS2019 Preview 4.4)
Additional Information
I got some help from @grendello to debug the issue and tried the following:
@grendello then asked me to try run the App with lldb. However, I didn't get that to work, it just made my App hang on splash screen and left some props on the device that made the subsequent launches of the app fail. I followed the instructions here: https://github.com/mono/lldb-binaries had to mess with the xa-lldb script to make it pick up the correct Main Activity and make it use msbuild because xabuild is not present on my machine.
After the failed lldb attempt, @grendello asked me to run
msbuild /bl /t:_Gdbon the App project, which didn't seem to crash the App. Which lead @grendello to the conclusion: "that means it might be a problem with sdb or triggered by it". And here we are.I cannot attach a repro sample, because I don't know which part of it actually triggers the App to blow up, since there is no stack trace to go from.
This issue seems to mainly happen on arm64 devices. My Nexus 5, doesn't have any issues with debugging.
Other people on Gitter.im had a similar issue.
The text was updated successfully, but these errors were encountered: