Native Crash Reporting - Got a SIGSEGV while executing native code while debugging background threads #3222
Comments
georgivzh
changed the title
georgivzh
changed the title
|
Thanks for the report! This looks interesting. The fact that the I tried a simple initial test of stepping through a few lines of code in a background thread in a small test app on an armeabi-v7a device, but unfortunately I haven't yet been able to reproduce the crash, so we'll need a bit more information to help investigate this issue. When you get chance, if you might be able to provide some of the following information, that would be perfect:
Thanks in advance! |
|
One other way to share a project privately that might be even easier:
|
|
Thanks for the log file! Curiously, it looks like that log file didn't capture any instances of the same crash from the original description. For example, there aren't any "E/mono-rt" lines in this log file. It looks like the app might have been stopped from the IDE via the "stop debugging" action. But if the IDE was stopping the app unexpectedly in some of these cases, that would be definitely be an issue. If you're still sometimes seeing crashes where the debug output shows "E/mono-rt", then if you get a chance to try collecting the |
|
I have reproduced it again. I see now E/mono-rt in the adblogcat. Maybe I haven't "catched" the correct timeframe in the previous log file. |
This comment has been minimized.
This comment has been minimized.
|
When is this gonna get released? The stable version of VS2019 has been completely broken for a month now! |
|
Indeed! This is a very serious blocking bug. |
|
@acaliaro, @tobiasschulz , @NickeManarin , based on the statistics of user reports of the issue and the information @acaliaro shared, it is likely that you are all seeing #3112 rather than this bug #3222. Issue #3112 only affects 64-bit arm64-v8a applications, like the one shown in @acaliaro 's crash log. In contrast, issue #3222 has so far been seen by @georgi8706 in a 32-bit armeabi-v7a application. I would recommend to follow #3222 for updates on the fixes for the issue that affects arm64-v8a applications. Thanks! |
|
@georgi8706 , thanks much for the additional log file, and apologies for the slow follow-up! The new adblogcat.txt contains the backtrace I was hoping for: Based on the |
|
I took a look at mono/mono#14772. Interestingly, I noticed that the scenario described there affects versions going back at least as far as Xamarin.Android 8.3. So a couple follow-up questions for you @georgi8706 : Did you only start to notice this problem after a recent update? (If so, there's a chance a change in a recent version might have added a new way to hit the old problem.) If you've noticed, have you usually seen this issue when single stepping in the background threads (using Step Over, Step Into, or Step Out)? Or have you sometimes seen it in other scenarios, like maybe sometimes just when landing on a breakpoint or inspecting a variable? The behavior in mono/mono#14772 seems to be tied to single stepping, so my hunch is that that's when you might be seeing the issue too. |
|
Hi, please see inline:
|
@brendanzagaeski You are right. :) I updated VS and it's working normally. |
|
I updated to 16.1.4 and still got the exception. The new log adblogcat.txt `=================================================================06-27 00:21:35.046 E/mono-rt (30788): /proc/self/maps: =================================================================
|
|
Thanks for the new results from Visual Studio 2019 version 16.1.4, and apologies again for this slow reply. One thing I was working on that delayed my reply is a set of steps for how to attach an unmanaged native debugger (LLDB or GDB) to Xamarin.Android. If by chance you might already have either Android Studio or the Android NDK installed (or if you wouldn't mind installing one of them), then one way to make sure the issue you are seeing matches mono/mono#14772 is to have you attach to your app with an unmanaged debugger and collect the stack backtrace when the SIGSEGV happens:
Alternatively, if by chance you have a self-contained test case that reproduces the issue, feel free to attach that back directly on this issue or use one of the other options to send it privately, and I can run the test with the unmanaged debugger. Thanks much! |
|
I have created a very simple project where I can reproduce it every time. I have uploaded it in a new repository called App1-SIGSEGV-crash. There is the project archived and called App1.rar.
|
|
Thanks for the test case! Sort of interestingly, I have so far only been able to hit a SIGSEGV in this
Result: This produces an unmanaged SIGSEGV fault, and the unmanaged backtrace at that point is the same as in mono/mono#14772. If I repeat steps 3–5 right after the first "No compatible code" message, I see the same "No compatible code" message again, but if I wait a couple dozen seconds before I repeat the steps, then the debugger seems to be able to read the break location correctly again. My guess is that this dependence on the particular timing could explain why you see the SIGSEGV already on step 3 in your environment. Given those results, I think the best way forward for this issue will be to track mono/mono#14772 for the fix. I will monitor that issue and update this issue when a candidate fix is available. |
|
I just wanted to ask if there is any progress on the issue, because I am still experiencing the problem in 16.2.5 and almost impossible to debug anything running in a background thread... |
|
Hi, yes! Apologies that it has been this long since the last status update on this issue. Just as of Monday this week, a new Preview version is available that includes the fix for mono/mono#14772. I haven't yet had a chance to try that version with the App1-SIGSEGV-crash test case. I will plan to do that soon. But if you already have or don't mind installing the side-by-side Visual Studio Preview version, you can check for the latest updates in that preview to install Visual Studio 2019 version 16.4 Preview 1, which includes Xamarin.Android 10.0.99.100, which includes the fix for mono/mono#14772. And you can try that version with your scenario to see how it behaves. |
|
Hi, that's fine. I will wait for the stable release :). Thanks. |
|
I came across this regularly while trying to debug CloudKit pushes for change notifications. In this case, VS stops at a given breakpoint but you cannot see a highlighted line and you cannot inspect variables at all. The only thing showing that it is actually pausing is the Run/Pause button. Pressing F5 causes the app to run and everything works fine. Pressing F10 or F11 immediately crashes the app with a SIGSEGV as mentioned above. But note that I am talking about Xamarin.iOS, not Android. Well, you won't like my pragmatic approach, but it works like a charm if you need to get things done: |
|
@brendanzagaeski I have just tried the App1-SIGSEGV-crash project in VS2019 Preview 4.0, and the issue seems to only partly have been fixed. |
|
@emimvi, thanks for the testing that scenario, and apologies for the slow reply. I had a chance to try the App1-SIGSEGV-crash project again myself today with the latest versions. I simplified the test case a little more to focus on the No compatible code running symptom and filed a new issue for further investigation: mono/mono#18106. I'm not sure if it will be useful info, but in the little experiments I tried with the test case, I only saw the issue when using the |
|
@brendanzagaeski |
|
@emimvi, yes, I experimented a bit more today with the behavior for In particular, today I noticed that there were several other reports from users who saw No compatible code running appear after they updated from Visual Studio 2017 to Visual Studio 2019, and I confirmed that the test case for |
|
This problem has started happening for us in a Xamarin.Android project after updating to Visual Studio 16.7. VS Output: Environment details: I've spent a while looking into it without finding a solution. As a workaround, I've disabled "Use Shared Runtime" in debug builds which allows the build to run but without debug capabilities (i.e. breakpoints will not be hit). Is anyone else getting this problem after updating to Visual Studio 16.7? Any suggested solutions would be appreciated. Thanks |
|
@dj-dev Shared runtime isn't needed for debugging (it's not its purpose), you might want to delete your bin/obj after disabling it, remove the app from device and then deploy it. Regarding the segfault, there's not enough information to be certain but it's very possible you hit #4983 (fixed in #4993, workaround in #4983 (comment)) |
|
Thanks @grendello , I had a look at #4983 and added the android:extractNativeLibs="true" setting to the manifest. After deleting bin/obj and rebuilding, breakpoints were still not being hit. I then tried enabling "Use Shared Runtime" and rebuilding, the app no longer crashed in debug builds and breakpoints started being hit again. As a sanity test, I tried again with Use Shared Runtime disabled and breakpoints were not hit (also deleted bin/obj before the test). It was also my understanding that Shared Runtime was not required for debugging, but since I normally have it enabled this is not an issue. So in my case at least, the solution was adding the android:extractNativeLibs="true" setting to the manifest and making sure "Use Shared Runtime" was enabled. For reference, I'm debugging directly on an Android 9 device. |
|
Facing same issue while presenting a Camera view controller on Xamarin.ios please find below details === Visual Studio Professional 2019 for Mac === Version 8.6.5 (build 23) === Mono Framework MDK === Runtime: === Roslyn (Language Service) === 3.6.0-3.20210.9+4eafdcb1bcbd8d3573f2ba6065e56d9b9ce4f8a3 === NuGet === Version: 5.6.0.6591 === .NET Core SDK === SDK: /usr/local/share/dotnet/sdk/3.1.301/Sdks === .NET Core Runtime === Runtime: /usr/local/share/dotnet/dotnet === Xamarin.Profiler === Version: 1.6.13.11 === Updater === Version: 11 === Xamarin.Android === Version: 10.3.1.4 (Visual Studio Professional) SDK Tools Version: 26.1.1 Build Information: === Microsoft OpenJDK for Mobile === Java SDK: /Users/vahidahavaldar/Library/Developer/Xamarin/jdk/microsoft_dist_openjdk_1.8.0.25 === Android SDK Manager === Version: 16.6.0.50 === Android Device Manager === Version: 16.6.0.96 === Apple Developer Tools === Xcode 11.5 (16139) === Xamarin.Mac === Version: 6.18.2.1 (Visual Studio Professional) === Xamarin.iOS === Version: 13.18.2.1 (Visual Studio Professional) === Xamarin Designer === Version: 16.6.0.329 === Build Information === Release ID: 806050023 === Operating System === Mac OS X 10.15.5 |
|
@Waaheeda, if you haven't yet resolved the issue you're seeing, I'd recommend updating to the latest Visual Studio 2019 for Mac version 8.7 release, and then if the issue still happens, submitting a new issue on the https://github.com/xamarin/xamarin-macios/ repository with the details of what you're seeing so the Xamarin.iOS team can take a look. If possible, including a minimal test case that demonstrates the problem would be excellent too. Thanks in advance! |
|
@brendanzagaeski I tried updating visual studio 2019 to latest version 8.8.6 and Xcode to 12.4 , still facing same issue =================================================================
|
jpobst
added
Area: Mono Runtime
|
Still observing the same issue after migrating MAUI. Project type .Net Native iOS, version .Net 7.0, Use case mostly when there is huge data in sqlite DB and downloading image from server and saving as image byte and navigating to next page. =================================================================
|
Steps to Reproduce
Reproduce using the following configuration:
The text was updated successfully, but these errors were encountered: